[Bug ld/31395] New: Wrong search path for DT_NEEDED libs on FreeBSD under gcc -m32

[brooks at freebsd dot org]

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.