[Bug bootstrap/35804] New: Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[Bug bootstrap/35804] New: Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

Hello,

This bug is a continuation from
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752 and
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. It appears that native
retargeting of the compiler is not supported in the 4.3/4.4 series in favor of
the sysroot option.  When trying to build a pass 1 compiler with combined gcc
and binutils in a single directory, sysroot seems to be appending an extra
sysroot prefix in the linker during libgcc linking.

The current build setup I'm trying is to install in order to the sysroot
directory of /tools:

Linux headers
glibc-pass-1 full compile with native toolchain so that crt files exist.
bootstrap gcc+binutils toolchain against new glibc.

I have tried configuring the gcc+binutils toolchain with the following three
sets of options and it still has the same problem:

configue --prefix=/tools/usr \
         --with-sysroot=/tools \
         --with-pic \
         --disable-nls \
         --disable-libmudflap \
         --disable-libssp \
         --enable-languages=c \
         --enable-checking=release \
         --disable-werror \
         --enable-bootstrap

configue --prefix=/tools/usr \
         --with-sysroot=/tools \
         --with-build-sysroot=/tools \
         --with-pic \
         --disable-nls \
         --disable-libmudflap \
         --disable-libssp \
         --enable-languages=c \
         --enable-checking=release \
         --disable-werror \
         --enable-bootstrap

configue --prefix=/usr \
         --with-sysroot=/tools \
         --with-build-sysroot=/tools \
         --with-pic \
         --disable-nls \
         --disable-libmudflap \
         --disable-libssp \
         --enable-languages=c \
         --enable-checking=release \
         --disable-werror \
         --enable-bootstrap

And building with:
LDFLAGS_FOR_TARGET="--sysroot=/tools" CPPFLAGS_FOR_TARGET="--sysroot=/tools"
make

Everything compiles up to stage 1 libgcc which errors out on the final link
command with the linker error of:
/media/disk-3/build/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot find
/tools/lib/libc.so.6 inside /tools

Unfortunately, /tools/lib/libc.so.6 exists and if I create a link to /tools
inside of the tools directory (recursive symlink) the link will complete and
continue to stage 2

I'm pretty sure I shouldn't have to create a link to . for this to work
properly .


-- 
           Summary: Bootstrap of combined gcc + binutils, with --enable-
                    shared, with sysroot fails
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: critical
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: oblivian at users dot sourceforge dot net
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2008-04-02 16:23 -------
Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
and CPPFLAGS_FOR_TARGET .


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|critical                    |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

------- Comment #2 from oblivian at users dot sourceforge dot net  2008-04-02 16:26 -------
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
> 
You mean configure with just --with-build-sysroot and not --with-sysroot and
remove LD/CPP FLAGS_FOR_TARGET from make?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[joseph at codesourcery dot com]

------- Comment #3 from joseph at codesourcery dot com  2008-04-02 17:52 -------
Subject: Re:  Bootstrap of combined gcc + binutils, with
 --enable-shared, with sysroot fails

On Wed, 2 Apr 2008, pinskia at gcc dot gnu dot org wrote:

> Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .

My experience is that you do need to set LDFLAGS_FOR_TARGET and 
CPPFLAGS_FOR_TARGET to include the --sysroot option if you're configuring 
with a build sysroot.  (This is a bug: --with-build-sysroot should cause 
the right --sysroot option to be used automatically when compiling and 
linking runtime libraries.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

------- Comment #4 from oblivian at users dot sourceforge dot net  2008-04-03 00:12 -------
(In reply to comment #1)
> Sounds like you should be using --build-sysroot= and not set LDFLAGS_FOR_TARGET
> and CPPFLAGS_FOR_TARGET .
> 

I pulled the compiler command that failed, and ran it with -v. I took that
command and  ran it with the current stage ld.
Here is what GCC tries to run when linking libgcc_s.so.1.tmp
--------------------------------------------------------------
/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld/ld-new
--sysroot=/tools --eh-frame-hdr -m elf_i386 -shared -o ./libgcc_s.so.1.tmp
/tools/usr/lib/crti.o
/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtbeginS.o
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc -L. -L/tools/lib
-L/tools/usr/lib --soname=libgcc_s.so.1 --version-script=libgcc.map _muldi3_s.o
_negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o
_clear_cache_s.o _enable_execute_stack_s.o _trampoline_s.o __main_s.o
_absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o
_mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o
_ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o
_popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o
_paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o
_muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o
_divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o
_fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixtfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _fixunstfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatditf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _floatunditf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o
_umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o unwind-dw2_s.o
unwind-dw2-fde-glibc_s.o unwind-sjlj_s.o gthr-gnat_s.o unwind-c_s.o emutls_s.o
-lc /media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/crtendS.o
/tools/usr/lib/crtn.o
-----------------------------------------------
The error is...
-----------------------------------------------
/media/disk/build/scripts/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot
find /tools/lib/libc.so.6 inside /tools

Now if I run the same command and take the /tools prefix off of the -L flags
for -L/tools/lib and -L/tools/usr/lib the library will link and running:

ldd libgcc_s.so.1.tmp 
        linux-gate.so.1 =>  (0xb7fce000)
        libc.so.6 => /tools/lib/libc.so.6 (0xb7e90000)
        /tools/lib/ld-linux.so.2 (0xb7fcf000)

So it seems that gcc should strip sysroot from the library paths if it is
calling a sysrooted ld, but should not if ld does not support sysroot.  Even
though the ld gets search directories without the sysroot prefix it is linking
against the correct target libraries.  For example, I can remove the --sysroot
from the first command above and run it with my host ld which doesn't support
sysroot (it's version 2.17 compiled the old way), and it will link the library
correctly and produce a ldd output the same as above pointing to the correct
locations.

Not sure where to go from here.

Also ran across a potential problem in binutils with elf32.em which does not
take into account sysroot correctly for the ld.so.conf path.  The use_sysroot
flag is passed to the script, but it needs to use TARGET_SYSTEM_ROOT not prefix
to point to the correct sysroot /etc/ld.so.conf.  For example my prefix for ld
configuration is /tools/usr whereas the sysroot is /tools.  elf32.em will look
for it in /tools/usr/etc/ld.so.conf even though glibc installed it in
/tools/etc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

------- Comment #5 from oblivian at users dot sourceforge dot net  2008-04-03 01:40 -------
Is this something special in the compiler specs for libc?

I created this test file conftest.c

#include <stdio.h>

int testing_lib()
{
        printf("hello world!\n");
        return 0;
}


And ran a scaled down libgcc command with the stage 1 compiler:

/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/xgcc
-B/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/
-B/tools/usr/i686-pc-linux-gnu/bin/ -B/tools/usr/i686-pc-linux-gnu/lib/
-isystem /tools/usr/i686-pc-linux-gnu/include -isystem
/tools/usr/i686-pc-linux-gnu/sys-include
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld -O2  -O2 -g -g
-O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1 -o ./conftest.so.1.tmp conftest.c -lm
-lc

------------------------------------------------------------------------------
conftest.c:4: warning: function declaration isn't a prototype
conftest.c: In function 'testing_lib':
conftest.c:4: warning: old-style function definition
/media/disk/build/scripts/tools/toolchain-pass-1/build/gcc/../ld/ld-new: cannot
find /tools/lib/libc.so.6 inside /tools
collect2: ld returned 1 exit status
------------------------------------------------------------------------------

Now running the same command without -lc

------------------------------------------------------------------------------
/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/xgcc
-B/media/disk/build/scripts/tools/toolchain-pass-1/build/./gcc/
-B/tools/usr/i686-pc-linux-gnu/bin/ -B/tools/usr/i686-pc-linux-gnu/lib/
-isystem /tools/usr/i686-pc-linux-gnu/include -isystem
/tools/usr/i686-pc-linux-gnu/sys-include
-L/media/disk/build/scripts/tools/toolchain-pass-1/build/./ld -O2  -O2 -g -g
-O2   -DIN_GCC    -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include  -fPIC -g
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED  -shared
-nodefaultlibs -Wl,--soname=libgcc_s.so.1 -o ./conftest.so.1.tmp conftest.c -lm 
conftest.c:4: warning: function declaration isn't a prototype
conftest.c: In function 'testing_lib':
conftest.c:4: warning: old-style function definition
-------------------------------------------------------------------------------
Despite the warnings it creates the shared library file

and running 

ldd conftest.so.1.tmp 
        linux-gate.so.1 =>  (0xb7eec000)
        libm.so.6 => /tools/lib/libm.so.6 (0xb7ebf000)
        /tools/lib/ld-linux.so.2 (0xb7eed000)
        libc.so.6 => /tools/lib/libc.so.6 (0xb7d94000)

The new file not only is linked with the correct libm, but also libc????

Where is this special handling of -lc?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

------- Comment #6 from oblivian at users dot sourceforge dot net  2008-04-03 03:24 -------
(In reply to comment #5)
Ok, so this is a sysroot bug in binutils that they marked as invalid
http://sourceware.org/bugzilla/show_bug.cgi?id=4966

I guess I would argue that it's not invalid anymore since this behavior is now
required with the removal of the spec search paths that allowed a minimal
"tools" toolchain to be installed before chrooting and compiling a new full
target toolchain without overwriting binaries.

I applied the change from that bug and now it continues on to stage 2.

This bug is now invalid and it will have to be straightened out with binutils.
My vote is of course this should be supported by sysroot, and not limited to a
root directory chrooted toolchain.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[oblivian at users dot sourceforge dot net]

------- Comment #7 from oblivian at users dot sourceforge dot net  2008-04-03 15:07 -------
They re-closed the binutils bug as invalid again and told me to open a new one.

So here's the new one http://sourceware.org/bugzilla/show_bug.cgi?id=6027
We'll see if it gets any more traction.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[amodra at bigpond dot net dot au]

------- Comment #8 from amodra at bigpond dot net dot au  2009-01-18 23:36 -------
I believe that this is a user error and that this bugzilla should be closed. 
Your problem with ld "cannot find /tools/lib/libc.so.6 inside /tools" is simply
that your glibc is built wrongly for your sysroot.  (glibc is not sysroot
aware.)  You'll find that the script libc.so has a line something like

GROUP ( /tools/lib/libc.so.6 /tools/usr/lib/libc_nonshared.a  AS_NEEDED (
/tools/lib/ld-linux.so.2 ) )

The /tools sysroot prefix ought not be present on any of these paths.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804

[Bug bootstrap/35804] Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails

[bonzini at gnu dot org]

------- Comment #9 from bonzini at gnu dot org  2009-01-19 06:05 -------
I agree with Alan.


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35804