View previous topic :: View next topic |
Author |
Message |
theraginggeek n00b
Joined: 30 May 2022 Posts: 15
|
Posted: Sun Apr 16, 2023 2:36 am Post subject: emerge of lsof failing |
|
|
been trying to resolve an issue I'm running into emerging lsof updates to 4.98.0. I tried emerging gcc and a few other updates I had queued up that might have been an ordering issue, and it didn't seem to make a difference.
it seems in print.c it's failing at reference to clnt_create
links to the pastebins below:
build log = https://pastebin.com/wUfMwb8R
emerge pqv = https://pastebin.com/rZTv9iyv
emerge info = https://pastebin.com/vLSe0YjB
any assistance in understanding the errors here are appreciated.
thanks |
|
Back to top |
|
|
fedeliallalinea Administrator
Joined: 08 Mar 2003 Posts: 30838 Location: here
|
Posted: Sun Apr 16, 2023 5:31 am Post subject: |
|
|
Code: | /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: lsof-print.o: in function `lkup_port':
print.c:(.text+0x7cb): undefined reference to `clnt_create'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: print.c:(.text+0x7e8): undefined reference to `xdr_pmaplist'
/usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: print.c:(.text+0x7f4): undefined reference to `xdr_void'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:1200: lsof] Error 1
make[1]: Leaving directory '/var/tmp/portage/sys-process/lsof-4.98.0/work/lsof-4.98.0'
make: *** [Makefile:904: all] Error 2 |
Try to rebuild net-libs/libtirpc package. _________________ Questions are guaranteed in life; Answers aren't. |
|
Back to top |
|
|
theraginggeek n00b
Joined: 30 May 2022 Posts: 15
|
Posted: Mon Apr 17, 2023 12:43 am Post subject: |
|
|
sadly no change, it emerged successfully, but lsof still continues to fail with the same error |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9507 Location: beyond the rim
|
Posted: Mon Apr 17, 2023 9:25 am Post subject: |
|
|
For some reason it includes those symbols in the code, but doesn't actually try to link to the necessary library. And with USE=-rpc it really shouldn't use those symbols.
Seems to be some automagic error where it finds the rpc header file and unconditionally defines the relevant macros ignoring the passed configure options. This is only exposed now due to logic changes in the lsof ebuild with the new version (old ebuilds likely just implicitly linked to libtirpc if it was installed as they didn't pass --without-libtirpc).
So the easy "solution" to get around this error is probably to specify USE=rpc for lsof. But the proper solution would be to patch its build system.
@fedeliallalinea: If I'm correct you can reproduce it by manually installing libtirpc and then attempting to build lsof with USE=-rpc.
Last edited by Genone on Mon Apr 17, 2023 2:09 pm; edited 3 times in total |
|
Back to top |
|
|
fedeliallalinea Administrator
Joined: 08 Mar 2003 Posts: 30838 Location: here
|
Posted: Mon Apr 17, 2023 9:32 am Post subject: |
|
|
theraginggeek,
can you post also config.log? In my system with rcp disable compilation work fine.
The difference is that in your configuration phase there is checking for rpc/rpc.h... yes in my checking for rpc/rpc.h... no. _________________ Questions are guaranteed in life; Answers aren't. |
|
Back to top |
|
|
theraginggeek n00b
Joined: 30 May 2022 Posts: 15
|
Posted: Mon Apr 17, 2023 8:02 pm Post subject: |
|
|
fedeliallalinea wrote: | theraginggeek,
can you post also config.log? In my system with rcp disable compilation work fine.
The difference is that in your configuration phase there is checking for rpc/rpc.h... yes in my checking for rpc/rpc.h... no. |
here's my config.log: https://pastebin.com/jWen94uW |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1582
|
Posted: Mon Apr 17, 2023 8:43 pm Post subject: |
|
|
This looks like some strange rpc.h hanging out where it not expected.
The ${S}/autotools/autotools.h.in file says if both rpc/rpc.h (in the include path) and libtirpc do not exist, skip RPC calls.
Here, one does exist so it tries to link after a successful inclusion.
So the question is, where is this file and does some package claim it.
Find out with find /usr -name rpc.h followed up with qfile on the results |
|
Back to top |
|
|
Genone Retired Dev
Joined: 14 Mar 2003 Posts: 9507 Location: beyond the rim
|
Posted: Tue Apr 18, 2023 7:48 am Post subject: |
|
|
grknight wrote: | The ${S}/autotools/autotools.h.in file says if both rpc/rpc.h (in the include path) and libtirpc do not exist, skip RPC calls. |
Yes, but if I'm reading it right it doesn't work correctly when libtirpc is installed, but explicitly disabled by configure, as the rpc.h check is performed unconditionally in configure.ac. So the HAVE_RPC_RPC_H macro gets defined, which causes the condition guarding the HASNORPC_H definition to fail and the rpc calls are getting compiled. But due to libtirpc being disabled by configure it is not passed to the linker.
Looks like a logic error to me, I'd expect an OR instead of an AND in that #if condition, at least for Linux. Or just not check for rpc.h in configure.ac if libtirpc is explicitly disabled. |
|
Back to top |
|
|
grknight Retired Dev
Joined: 20 Feb 2015 Posts: 1582
|
Posted: Tue Apr 18, 2023 12:55 pm Post subject: |
|
|
Genone wrote: | grknight wrote: | The ${S}/autotools/autotools.h.in file says if both rpc/rpc.h (in the include path) and libtirpc do not exist, skip RPC calls. |
Yes, but if I'm reading it right it doesn't work correctly when libtirpc is installed, but explicitly disabled by configure, as the rpc.h check is performed unconditionally in configure.ac. So the HAVE_RPC_RPC_H macro gets defined, which causes the condition guarding the HASNORPC_H definition to fail and the rpc calls are getting compiled. But due to libtirpc being disabled by configure it is not passed to the linker.
Looks like a logic error to me, I'd expect an OR instead of an AND in that #if condition, at least for Linux. Or just not check for rpc.h in configure.ac if libtirpc is explicitly disabled. |
Not everyone may be on libtirpc yet as older glibc had rpc IIRC.
In addition, libtirpc's rpc/rpc.h isn't in the default include path that I can tell (installed to /usr/include/tirpc/rpc/rpc.h). When net-libs/libtirpc is installed and rpc USE is disabled for sys-process/lsof, I still get the "checking for rpc/rpc.h... no".
So the question remains where is this rpc/rpc.h coming from? |
|
Back to top |
|
|
pyeatt n00b
Joined: 10 May 2023 Posts: 2
|
Posted: Wed May 10, 2023 1:53 am Post subject: |
|
|
I just added "=sys-process/lsof-4.98.0" to /etc/portage/package.mask/package.mask" Nothing depends on lsof, Rebuild of world works. I'll let upstream work out the problem. _________________ Larry D. Pyeatt, PhD.
Department of Electrical Engineering and Computer Science
South Dakota School of Mines and Technology
larry.pyeatt@sdsmt.edu |
|
Back to top |
|
|
|