[Bug build/19425] New: libc.so link script content doesn't respect sysroot

["4ernov at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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

            Bug ID: 19425
           Summary: libc.so link script content doesn't respect sysroot
           Product: glibc
           Version: 2.22
            Status: NEW
          Severity: normal
          Priority: P2
         Component: build
          Assignee: unassigned at sourceware dot org
          Reporter: 4ernov at gmail dot com
                CC: carlos at redhat dot com
  Target Milestone: ---

I'm building temporary cross-compilation toolchain to upgrade my current
toolchain in LFS and faced the problem. I mentioned it before, but this time
decided to post a report for it.

The problem is in link script $SYSROOT/lib/libc.so being created during Glibc
installation. It contains absolute paths, as Makerules reads: "We need to use
absolute paths since otherwise local copies (if they exist) of the files are
taken by the linker.", but these absolute paths are unfortunately taken not
against SYSROOT, but host root directory:

echo 'GROUP ( $(slibdir)/libc.so$(libc.so-version)' \
              '$(libdir)/$(patsubst %,$(libtype.oS),$(libprefix)$(libc-name))'\
              ' AS_NEEDED (' $(rtlddir)/$(rtld-installed-name) ') )'

where
slibdir = $(exec_prefix)/lib
libdir = $(exec_prefix)/lib
rtlddir = $(slibdir)
exec_prefix = $(prefix)

But ld performs the search if these libraries upon SYSROOT, which results in
SYSROOT part being applied two times, and, of course, search fails, e.g.:

cannot find /usr/src/toolchain/01012016/tools/lib/libc.so.6 inside
/usr/src/toolchain/01012016

Here's my example and steps to reproduce:

0. export LFS="/usr/src/toolchain/01012016"

1. Binutils-2.25.1:
../binutils-2.25.1/configure   \
    --prefix=$LFS/tools        \
    --with-sysroot=$LFS        \
    --with-lib-path=/tools/lib \
    --target=$LFS_TGT          \
    --disable-nls              \
    --disable-werror

2. GCC-5.3.0:
../gcc-5.3.0/configure                                 \
    --target=$LFS_TGT                                  \
    --prefix=$LFS/tools                                \
    --with-glibc-version=2.11                          \
    --with-sysroot=$LFS                                \
    --with-newlib                                      \
    --without-headers                                  \
    --with-local-prefix=/tools                         \
    --with-native-system-header-dir=$LFS/tools/include \
    --disable-nls                                      \
    --disable-shared                                   \
    --disable-multilib                                 \
    --disable-decimal-float                            \
    --disable-threads                                  \
    --disable-libatomic                                \
    --disable-libgomp                                  \
    --disable-libquadmath                              \
    --disable-libssp                                   \
    --disable-libvtv                                   \
    --disable-libstdcxx                                \
    --enable-languages=c,c++

Also patched with the patch described in
(http://www.linuxfromscratch.org/lfs/view/development/chapter05/gcc-pass1.html).

3. Glibc-2.22:
../glibc-2.22/configure                             \
      --prefix=$LFS/tools                           \
      --host=$LFS_TGT                               \
      --build=$(../glibc-2.22/scripts/config.guess) \
      --disable-profile                             \
      --enable-kernel=2.6.32                        \
      --enable-obsolete-rpc                         \
      --with-headers=$LFS/tools/include             \
      libc_cv_forced_unwind=yes                     \
      libc_cv_ctors_header=yes                      \
      libc_cv_c_cleanup=yes

And finally "echo 'int main(){}' > dummy.c && $LFS_TGT-gcc dummy.c" prints:
/usr/src/toolchain/01012016/tools/lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
cannot find /usr/src/toolchain/01012016/tools/lib/libc.so.6 inside
/usr/src/toolchain/01012016
/usr/src/toolchain/01012016/tools/lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
cannot find /usr/src/toolchain/01012016/tools/lib/libc_nonshared.a inside
/usr/src/toolchain/01012016
/usr/src/toolchain/01012016/tools/lib/gcc/x86_64-lfs-linux-gnu/5.3.0/../../../../x86_64-lfs-linux-gnu/bin/ld:
cannot find /usr/src/toolchain/01012016/tools/lib/ld-linux-x86-64.so.2 inside
/usr/src/toolchain/01012016
collect2: error: ld returned 1 exit status

When manually editing /usr/src/toolchain/01012016/tools/lib/libc.so and
removing sysroot part from absolute paths (/usr/src/toolchain/01012016/tools ->
/tools etc.), everything starts working fine:
> readelf -l a.out | grep ': /tools'
      [Requesting program interpreter: /tools/lib64/ld-linux-x86-64.so.2]

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