On recent CURRENT (FreeBSD 15.0-CURRENT #29 main-n265348-03bfee175269: Fri Sep 15 07:01:12 CEST 2023 amd64) port emulators/qemu-user-static fails to build due to the following linker error: [...] ld: error: undefined symbol: elf_getphnum >>> referenced by core.c >>> core.o:(procstat_core_open) in archive /usr/lib/libprocstat.a >>> did you mean: elf_getshnum >>> defined in: /usr/local/lib/libelf.a(elf_getshdrnum.o) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [Makefile:201: qemu-i386] Error 1 gmake[2]: Leaving directory '/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-527096e0c8/i386-bsd-user' gmake[1]: *** [Makefile:483: subdir-i386-bsd-user] Error 2 ld: error: undefined symbol: elf_getphnum >>> referenced by core.c >>> core.o:(procstat_core_open) in archive /usr/lib/libprocstat.a >>> did you mean: elf_getshnum >>> defined in: /usr/local/lib/libelf.a(elf_getshdrnum.o) c++: error: linker command failed with exit code 1 (use -v to see invocation) gmake[2]: *** [Makefile:201: qemu-arm] Error 1 gmake[2]: Leaving directory '/usr/ports/emulators/qemu-user-static/work/qemu-bsd-user-527096e0c8/arm-bsd-user' gmake[1]: *** [Makefile:483: subdir-arm-bsd-user] Error 2
(In reply to O. Hartmann from comment #0) I guess your error happens in an unclean environment? This happens to me too (15.0-CURRENT amd64 main-n265294-52d4a4d4e0de). In Poudriere the port is built as expected and is usable.
It builds for me too in poudriere: qemu-user-static: 3.1.0_14 built in 15.0-CURRENT 1500001 4c52dde5bd amd64. Can you try in a build environment?
This seems to be a problem if ports devel/elfutils is installed. It is not a dependency of qemu-user-static (nor any of ITS dependencies), so in a single port build of qemu-user-static in poudriere, it would not show up as a failure. Simple patch that leaps to mind would be to use "/usr/lib/libelf.so" in the LIBS specification for FreeBSD in the 'configure' script (instead of "-lelf"). devel/elfutils is two releases behind (0.187 April 2022 vs 0.189 in March 2023). I have not checked to see if that would help yet.
elf_getphnum() is deprecated (as is elf_getshnum()) according to /usr/include/libelf.h. This deprecation is noted in the base source tree in contrib/elftoolchain and in elfutils source as well. It has been deprecated in elfutils since 2009. elf_getphdrnum() is identical to elf_getphnum in both implementations (elftoolchain and elfutils). I would patch emulators/qemu-user-static to use elf_getphdrnum(). And look into submitting report and/or patch upstream.
(In reply to John Hein from comment #3) elfutils 0.189 fails as well. It has no symbol defined for getphnum.
(In reply to John Hein from comment #4) I said: "elf_getphdrnum() is identical to elf_getphnum in both implementations (elftoolchain and elfutils)." I meant to say: elf_getsnum() is identical to elf_getshdrnum in both implementations (elftoolchain and elfutils). elf_getphnum() is identical to elf_getphdrnum in elftoolchain and elfutils only has getphdrnum(). In elfutils, getphdrnum() was not added until after the getshnum() deprecation (in 2009). I would guess that when elf_getphdrnum() was added in 2009, the thinking was to not add an alternate signature (elf_getphnum()) that would be not recommended (deprecated) at birth.
(In reply to John Hein from comment #4) "I would patch emulators/qemu-user-static to use elf_getphdrnum(). And look into submitting report and/or patch upstream." I would also consider updating libprocstat in base to not use deprecated elf API functions (elf_getphnum in particular).
(In reply to John Hein from comment #7) See also bug 273966
(In reply to John Hein from comment #4) "elf_getphdrnum() is identical to elf_getphnum in both implementations (elftoolchain and elfutils)." Correction: The implementation of elf_getphnum() and elf_getphdrnum() are not quite identical. The return value for errors is 0 for the former and -1 for the latter. Same for elf_getshnum() vs elf_getshdrnum() (in both elftoolchain and elfutils).
Created attachment 245188 [details] [patch] fix build failure linking elfutils version of libelf (and missing dep) Attached is a patch to fix this build failure. (1) It now includes an ELFUTILS option to use the devel/elfutils version of libelf. (2) It uses -L/usr/lib otherwise (default is to use base libelf). (3) While here, shuffle a few variables per portclippy's recommendations. (4) Bump PORTREVISION - the package changes with the ELFUTILS option addition. This will link with the base libelf if ELFUTILS is off (which is the default). And if someone chooses to enable ELFUTILS, the dependency will be recorded. I considered marking the ELFUTILS option broken if enabled, but there is a fix already committed (bug 273966) in base libprocstat to use elf_getphdrnum() instead of the deprecated elf_getphnum() - with pending MFCs. That will fix this build failure as it makes its way into FreeBSD releases. Since ELFUTILS is not enabled by default and the "fix is coming soon" in base, I decided against marking it broken at this time. I leave it to the committer to decide to add that, if desired. If we get a lot more bug reports due to people trying to enable ELFUTILS, we can then change course, and mark it broken for appropriate FreeBSD versions. I suspect most qemu ports users will be perfectly happy linking with the base version of libelf. Now in case elfutils is installed, there will no longer be an unrecorded link dependency on <localbase>/lib/libelf.so. Either it will link with /usr/lib/libelf.so or it will link with <localbase>/lib/libelf.so and the dependency will be recorded (needs an updated libprocstat to be able to link with elfutils' libelf). QA: portlint, portclippy, poudriere builds - OK ====== I did also check emulators/qemu ports to see if it needs a similar treatment to build in case devel/elfutils is installed. It appears that it does not. 'make configure' finds /usr/lib/libelf.so even if elfutils is installed: -- Found LIBOMPTARGET_DEP_LIBELF: /usr/lib/libelf.so If we want to support using libelf from devel/elfutils for emulators/qemu, then an ELFUTILS options could be added separately, but it's not needed to fix a build problem and therefore not directly relevant to resolve this bug 273845.