https://sourceware.org/bugzilla/show_bug.cgi?id=31395
Bug ID: 31395 Summary: Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32 Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: brooks at freebsd dot org Target Milestone: --- When invoked via gcc -m32 on a FreeBSD amd64 system, ld searches for DT_NEEDED libraries as though it were on an i386 system and thus fails to find them. (This is likely also true for aarch64 and powerpc64, but I have not verified this is the case.) I think there is a communication breakdown between gcc and ld that I'm hoping can be resolved in ld because we maintain a single binutils package and 9 modern-ish gcc packages. On FreeBSD we've recently added a libsys which contains system call implementations and is linked into libc and libthr/libpthread. This has caused problems when building 32-bit binaries on 64-bit systems using gcc -m32 because ld fails to find libsys.so.7 unless it is listed explicitly on the command line. Confusingly that is true even though gcc passes -L/usr/lib/../lib32 to ld. I belive this is due to this logic: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldelf.c;h=04045acbf3dc56947edb15effff5818dd5b69fd9;hb=HEAD#l1091 Tracing of the gcc -m32 command performed by configure as part of a gcc12 multilib build confirms that ld tries a number of locations before failing to find libsys.so.7 and subsequently encountering unresolved symbols: ... 82890 ld NAMI "/usr/lib/libsys.so.7" 82890 ld NAMI "/usr/lib/compat/libsys.so.7" 82890 ld NAMI "/usr/local/lib/libsys.so.7" 82890 ld NAMI "/usr/local/lib/compat/pkg/libsys.so.7" 82890 ld NAMI "/usr/local/lib/perl5/5.36/mach/CORE/libsys.so.7" 82890 ld NAMI "/usr/local/i386-portbld-freebsd15.0/lib/libsys.so.7" 82890 ld NAMI "/lib/libsys.so.7" 82890 ld NAMI "/usr/lib/libsys.so.7" 82890 ld NAMI "/usr/local/lib/libsys.so.7" 82890 ld NAMI "/lib/libsys.so.7" 82890 ld NAMI "/usr/lib/libsys.so.7" 82890 ld NAMI "/usr/lib/compat/libsys.so.7" 82890 ld NAMI "/usr/local/lib/libsys.so.7" 82890 ld NAMI "/usr/local/lib/compat/pkg/libsys.so.7" 82890 ld NAMI "/usr/local/lib/perl5/5.36/mach/CORE/libsys.so.7" 82890 ld NAMI "/usr/local/i386-portbld-freebsd15.0/lib/libsys.so.7" 82890 ld NAMI "/lib/libsys.so.7" 82890 ld NAMI "/usr/lib/libsys.so.7" 82890 ld NAMI "/usr/local/lib/libsys.so.7" ... ("/lib/libsys.so.7" is found and opened, but presumably rejected due to the ABI mismatch.) Further tracing shows that gcc attempts to communicate the correct paths via a LIBRARY_PATH variable, but I don't think binutils looks for that at all: LIBRARY_PATH=/wrkdirs/usr/ports/lang/gcc12/work/.build/./gcc/32/:/usr/lib/../lib 32/:/wrkdirs/usr/ports/lang/gcc12/work/.build/./gcc/:/usr/local/x86_64-portbld-f reebsd15.0/bin/:/usr/local/x86_64-portbld-freebsd15.0/lib/:/lib/:/usr/lib/ (The presence of x86_64-portbld-freebsd15.0 suggests that gcc isn't getting this quite right either...) It seems like the current model is that ld knows nothing about -m32 which is fine to a point, but seems pretty broken here as at most one of the searched paths contain libaries of the wrong ABI. I don't know if ld should be honoring LIBRARY_PATH, searching /usr/lib32 unconditionally on 32-bit FreeBSD platforms, or something else? It's not really practical to add -lsys to the command line because that needs to happen places like inside gcc's multilib configure scripts that use the bootstrapped xgcc. I'm currently working around this issue by linking libc and libthr for 32-bit compat with --rpath=/usr/lib32, but this seems wrong as I'd ideally be able to use native i386 binaries to populate /usr/lib32. -- You are receiving this mail because: You are on the CC list for the bug.