[Bug ld/21250] New: ld --sysroot without --with-sysroot searches default dirs

[ro at gcc dot gnu.org]

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

            Bug ID: 21250
           Summary: ld --sysroot without --with-sysroot searches default
                    dirs
           Product: binutils
           Version: 2.28
            Status: NEW
          Severity: normal
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: ro at gcc dot gnu.org
  Target Milestone: ---

Playing around with gcc --sysroot, I noticed a weird ld behaviour.  I've
observed
this with native gcc mainline and gld 2.28, on both i386-pc-solaris2.12 and
x86_64-pc-linux-gnu, so I suppose it's target independent:

* When binutils have been configured without --with-sysroot and I point gcc at
  a non-existant/empty --sysroot directory, header files aren't found during
  compilation, just as expected.

  Once I add a copy of usr/include, compilation succeeds but startup files gcc
  searches itself (like crt1.o and friends) aren't found.

  Adding them (to <sysroot>/usr/lib instead of <sysroot>/usr/lib64 as I'd would
  have expected on Linux) causes both the startup files to be found and the
link
  to succeed *although there's no libc.so/libc.so.6 below <sysroot>*.

* However, if I configure binutils with --with-sysroot pointing to a
non-existant
  directory, the exact same ld invocation now fails to find libc.so, as it
should.

* Unlike ld, gold (2.27 in this case) gets this right, however: a default gold
  build doesn't find libc.so if it's missing below <sysroot>.

Besides, ld.texinfo incorrectly claims that --sysroot only works when binutils
have been configured with --with-sysroot, which is no longer true.  It seems
this
was true until binutils 2.25,however.

  Rainer

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