Bug 1040

Summary: Many packages fail to compile with binutils 2.16.1 because of ldscripts screwup
Product: binutils Reporter: Sunil <funtoos>
Component: ldAssignee: unassigned
Status: RESOLVED INVALID    
Severity: critical CC: bug-binutils
Priority: P1    
Version: 2.16   
Target Milestone: ---   
Host: i386-sun-solaris2.11 Target: i386-sun-solaris2.11
Build: i386-sun-solaris2.11 Last reconfirmed:

Description Sunil 2005-07-01 04:40:05 UTC
With binutils 2.16.1, lots of packages fail with wierd linker errors like some
library required by another library not found and then it dies with 'undefined
references'. All this happens because scripts in ldscripts/ only have
/usr/i386-sun-solaris2.11/lib in the SEARCH_DIR. ld doesn't see libraries lying
in /lib and /usr/lib. Changing these scripts to include /lib and /usr/lib solves
these problems. I couldn't figure out why -L/lib -L/usr/lib was not honoured(in
hindsight I think may be I needed to use -R/lib -R/usr/lib).

can you please include these paths by default in the SEARCH_DIR?
Comment 1 drow@false.org 2005-07-01 13:44:06 UTC
Subject: Re:  New: Many packages fail to compile with binutils 2.16.1 because of ldscripts screwup

On Fri, Jul 01, 2005 at 04:40:07AM -0000, funtoos at yahoo dot com wrote:
> With binutils 2.16.1, lots of packages fail with wierd linker errors like some
> library required by another library not found and then it dies with 'undefined
> references'. All this happens because scripts in ldscripts/ only have
> /usr/i386-sun-solaris2.11/lib in the SEARCH_DIR. ld doesn't see libraries lying
> in /lib and /usr/lib. Changing these scripts to include /lib and /usr/lib solves
> these problems. I couldn't figure out why -L/lib -L/usr/lib was not honoured(in
> hindsight I think may be I needed to use -R/lib -R/usr/lib).

(Not -R, but -rpath-link.)

How did you configure and build binutils?  It should have done this
automatically.

>  GCC build triplet: i386-sun-solaris2.11

... huh.  Is that right?  Last I heard there was only 2.10.

Comment 2 Sunil 2005-07-01 14:17:34 UTC
latest opensolaris bits are 2.11 already. the binutils was configured and built
using portage ebuilds. these are the configure args (I don't see much in them
pointing to this error, although you are better judge):

./configure --prefix=/usr --host=i386-sun-solaris2.11
--target=i386-sun-solaris2.11
--datadir=/usr/share/binutils-data/i386-sun-solaris2.11/2.16.1
--infodir=/usr/share/binutils-data/i386-sun-solaris2.11/2.16.1/info
--mandir=/usr/share/binutils-data/i386-sun-solaris2.11/2.16.1/man
--bindir=/usr/i386-sun-solaris2.11/binutils-bin/2.16.1
--libdir=/usr/lib/binutils/i386-sun-solaris2.11/2.16.1
--libexecdir=/usr/lib/binutils/i386-sun-solaris2.11/2.16.1
--includedir=/usr/lib/binutils/i386-sun-solaris2.11/2.16.1/include
--enable-shared --enable-64-bit-bfd --disable-werror --disable-nls
--build=i386-sun-solaris2.11
Comment 3 Alan Modra 2005-08-23 07:46:23 UTC
I built current mainline binutils using these configure params.  This resulted in
$ head elf_i386_ldso.x
/* Default linker script, for normal executables */
OUTPUT_FORMAT("elf32-i386", "elf32-i386",
              "elf32-i386")
OUTPUT_ARCH(i386)
ENTRY(_start)
SEARCH_DIR("/usr/i386-sun-solaris2.11/lib");
SEARCH_DIR("/usr/lib/binutils/i386-sun-solaris2.11/2.16.1");
SEARCH_DIR("/usr/local/lib"); SEARCH_DIR("/usr/ccs/lib"); SEARCH_DIR("/lib");
SEARCH_DIR("/usr/lib");
SECTIONS
{
  /* Read-only sections, merged into text segment: */
  PROVIDE (__executable_start = 0x08048000); . = 0x08048000 + SIZEOF_HEADERS;

As you can see, the search dirs are all there.  Is the problem that your
compiler is invoking the linker with the wrong -m emulation?
Comment 4 H.J. Lu 2007-07-11 20:10:10 UTC
Does the current binutls in CVS work?
Comment 5 Sunil 2007-07-11 20:15:49 UTC
I haven't used solaris for a while now and I would say close this bug if no one
else has seen this issue.
Comment 6 Alan Modra 2009-10-14 14:12:08 UTC
.