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

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31395

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nickc at redhat dot com

--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Brooks Davis from comment #0)
Hi Brooks,

> 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. 

Err, maybe I am misunderstanding this, but doesn't using -m32 imply that the
linker should act as if it is building for an i386 system ? 


> 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

Which makes sense.  That logic is duplicating how the system loader works, and
since the system loader does not have access to the -L options generated by
gcc, that code also ignores them.


> 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:

It doesn't - and nor does the system loader.  But if gcc used LD_LIBRARY_PATH,
that might work.

Does FreeBSD support cross linking ?  If not, then would a patch like this
solve your problem:

diff --git a/ld/configure.tgt b/ld/configure.tgt
index f937f78b876..a68f2313850 100644
--- a/ld/configure.tgt
+++ b/ld/configure.tgt
@@ -1113,7 +1113,7 @@ case "${target}" in
   ;;

 *-*-freebsd*)
-  NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib'
+  NATIVE_LIB_DIRS='/lib /usr/lib /usr/local/lib /lib/lib32'
   ;;

 hppa*64*-*-hpux11*)


How is the linker configured ?
In particular does it support the elf_i386_fsbd emulation ?
If it does, what shows up the SEARCH_DIR entries for that emulation's built in
script ?   ie:

  ld -m elf_i386_bfd --verbose | grep SEARCH_DIR

On my (cross-hosted) build I get:

  SEARCH_DIR("/usr/local/i386-pc-freebsd/lib32");
SEARCH_DIR("/usr/local/i386-pc-freebsd/lib");

Which implies to me that the linker already knows about the /lib32 directory,
but since I am running a cross-hosted linker, it prepends
/usr/local/i386-pc-freebsd/ to the path.

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.