[Bug bootstrap/35451] New: stage2 bootstrap xgcc infinite loop
When bootstrapping for a new system based off of HLFS using:
Binutils 2.18
Glibc 2.7
Gcc 4.3.0-20080228 (checked out from gcc-4_3-branch)
The host os system for build is:
Binutils 2.17
Glibc 2.5
Gcc 4.1.2
Build order was:
pass 1 4.3.0 bootstrap toolchain with configure of:
--prefix=/tools \
--with-local-prefix=/tools --with-pic --disable-nls \
--disable-libmudflap --disable-libssp \
--enable-languages=c --enable-checking \
--enable-werror --enable-bootstrap
glibc 2.7 with a configure of:
--prefix=/tools \
--with-binutils=/tools/bin --with-headers=/tools/include \
--enable-kernel=2.6.0 --enable-bind-now --enable-add-ons \
--without-gd --with-selinux --with-tls --disable-profile
pass 2 4.3.0 bootstrap toolchain with configure of:
--prefix=/tools \
--with-local-prefix=/tools --enable-shared \
--enable-clocale=gnu --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--with-lib-path=/tools/lib --disable-libstdcxx-pch \
--enable-checking --disable-werror
When bootstrapping pass 2 the xgcc for stage1 will go into an infinite loop and
starts to eat all available memory when trying to compile this simple program:
int main(void)
{
;
return 0;
}
running the stage1 xgcc under gdb shows it getting stuck in __kernel_vsyscall.
I can pull the 4.3.0 snapshot out of my build system and replace it with 4.2.3
and it builds with no problems.
I've tried to use binutils-2.18.50.0.4 and glibc-2.7.90 with Fedora patches as
well with no luck (4.3.0 still has the same infinite loop).
I'm thinking from my results that the problem is some where with 4.3.0 being
used to compile 4.3.0, since the initial pass 1 compiler bootstraps ok and is
being built with 4.1.2, and also the 4.2.3 compiles just fine with the
glibc-2.7 and binutils-2.18?
I had to move on so I went forward with 4.2.3 and continued with the build, so
when I get a chance I'll rerun the build with 4.3.0 and pull the build logs and
gdb output.
--
Summary: stage2 bootstrap xgcc infinite loop
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
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=35451
[Bug bootstrap/35451] stage2 bootstrap xgcc infinite loop
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-03-25 04:05 --- I've started over using the 4.3.0 release source files instead of svn and still have the same problem. After more checking I've narrowed this down to stage 2 ld-new, collect2 and the xgcc from stage 1. The do_spec_1 routine shows argbuf getting loaded with the path to ./prev-gcc/xgcc instead of a -L./prev-gcc/ linker directory. This causes collect2 or the executor (I'm still not clear on the run path) to run xgcc again which loads with the wrong argbuf again and calls collect2 again and so on until it eats all memory obviously. If I copy the ld-new from prev-ld to the stage2 ld directory the stage2 compiler will run and inserts -L./prev-gcc ok. I'm still trying to track down if this is a binutils ld problem or if binutils is broken by 4.3.0. I know first indication is that ld and therefore binutils is broken, but as I said before the exact same setup with 4.2.3 works fine. Also, I've now tried the compile setup I stated before, except on a gcc 4.2.3, binutils 2.18 and glibc 2.7 system as the host. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451
[Bug bootstrap/35451] stage2 bootstrap xgcc infinite loop
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-03-31 13:06 --- Ok, I've now recompiled about a million times with multiple sets of configure flags and cannot get a stage 1 gcc to compile stage 2 ld correctly. I've got some runs that exhibit the problem of infinite loop and others that just plain segfault based on how the configure flags are set. I've been searching endlessly and the closest thing I can find to the problem I'm running into is bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532. I've used this sysroot approach also to no-avail. In any configuration I try, the host compiler will produce a stage 1 gcc 4.3.0 and ld 2.18 that work as far as compiling a simple hello world app, but in the bootstrap case the gcc 4.3.0 stage 1 creates a hosed ld stage 2. I have also noticed that most of the methods out there don't bootstrap a compiler so I'm pretty sure this case is way under tested. I'm really starting to think (after starring at the differences between the 4.2.3 and 4.3.0 code bases) that the new libtool implementation in 4.3.0 is the problem. I finally noticed that 4.2.3 still had the old ltcf-c.sh files where as 4.3.0 has them removed. It appears that any attempt to bootstrap a compiler with libraries located in other than /lib or /usr/lib will not create a usable ld executable. Should a bootstrap a compiler methodology no longer be used with 4.3.0 to build a new native system? Any pointers to mailing lists I may have missed for answers would be appreciated as well. I've searched for days with nothing that seems remotely close (except for the bug above, if you can call that close). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #6 from oblivian at users dot sourceforge dot net 2008-03-31 20:29 --- Hi guys, I'm moving over from 35451 since it was marked as a duplicate and marked as resolved. I'm glad I'm not nuts and this is a problem someone else has, but... I've got a problem with the definition of this bug and the "fix" as it relates to my problem. Please note that I can bootstrap 4.3 just fine and it works as long as the libraries it's building against are in the root directory (e.g. /lib /usr/lib). It fails when it tries to bootstrap against the new glibc in /tools/lib. I'll try the patch and let you know if it worked in about 4 hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #8 from oblivian at users dot sourceforge dot net 2008-03-31 23:09 --- I am convinced that the patch is almost certainly wrong, is not the root cause of the problem, and the 4.3.0 implementation of libtool is almost certainly broken. While the patch allows the compiler to be built in phase 2 and complete, it is pulling in libraries from the host system. 4.2.3 Most certainly did not. I'm looking at build logs from both versions and for example the 4.2.3 build configure log for phase 2 showed that it could not find libflex -lfl for all stages of the build, where as 4.3.0 can't find -lfl in stage 1 and in stage 2 and follow it all of a sudden starts finds it. Since flex is not installed until after the phase 2 toolchain it should not be found by the compiler if it is searching /tools/lib for the whole bootstrap build. Beyond this bfd in stage 2 of the phase 2 compiler is showing sys_lib_search_path_spec with /lib and /usr/lib in it, which is very bad for the phase 2 compiler I'm trying to build. I'm going to start looking into where sys_lib_search_path_spec is set and find the deltas between the two versions since I'm not sure where else to look. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #9 from oblivian at users dot sourceforge dot net 2008-03-31 23:25 --- (In reply to comment #8) > I'm going to start looking into where sys_lib_search_path_spec is set and find > the deltas between the two versions since I'm not sure where else to look. > So looking at the delta between the two libtool files in stage 1 and stage 2 bfd shows: -sys_lib_search_path_spec="/media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/ usr/lib/gcc/i686-pc-linux-gnu/4.3.0 /media/disk-3/tools-006eaa66298e39accdc34d3c a2530559/usr/lib/gcc /media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/usr/i6 86-pc-linux-gnu/lib /media/disk-3/tools-006eaa66298e39accdc34d3ca2530559/usr/lib /lib /usr/lib" +sys_lib_search_path_spec="/media/disk-3/build/scripts/tools/toolchain-pass-2/bu ild/prev-gcc /tools-006eaa66298e39accdc34d3ca2530559/usr/i686-pc-linux-gnu/bin / lib /usr/lib" The - is the stage 1 bfd build directory and + is the stage 2 bfd. Libtool is not including the tools library directories in stage 2. Please ignore the uuid I use to differentiate tools directories since they are symlinked to the host system's root directory. Note this is currently with the exec-tools.in patch applied. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #11 from oblivian at users dot sourceforge dot net 2008-04-01 10:24 --- (In reply to comment #10) > Subject: Re: [4.3/4.4 Regression]: Combined gcc + binutils > source tree doesn't bootstrap > # When ld-new is first executed from the build tree, libtool > # will relink it as .libs/lt-ld-new, so that it can give it > # an RPATH that refers to the build tree. While doing this > # we need to use the previous-stage linker, or we have an infinite > # loop. That doesn't make sense from what I'm seeing, so either I need to reopen the bug that I submitted or we are headed down the wrong path. The stage 1 ld works as far as linking the stage 1 gcc which is directly after it. It's only when we get to stage 2 that things break. If the above were true, I would not be able to get to stage 2 since the stage 1 ld would have to use the host ld to link itself and from the logs I have... >From stage 1 gcc configure output: checking what linker to use... newly built ld And gcc stage 1 compiles and links. Beyond this, I will reiterate that I can do a complete bootstrap of the 4.3.0 compiler in phase 1, without this patch, and it completes building all stages and works. The compiler in phase 2 of the build, when linking against libraries not in the root /lib and /usr/lib directories is what is confusing the stage 2 programs and not allowing it to work. It appears after more searching that binutils configure scripts are trying to pull the sys_lib_search_path_spec variable from the stage 1 xgcc for all stage 2 programs, and that stage 1 gcc is building and linking against correct library paths, but not incorporating those paths into it's output for -print-search-dirs. Since it doesn't have these paths correctly sys_lib_search_path_spec is set incorrectly by stage 2 configure in ld and libtool gets generated with incorrect library paths thus infecting itself with the host libraries and causing havoc to ensue with the build. So to summarize what I see: Stage 1 ld is built against /tools/lib libraries Stage 1 gcc is built against /tools/lib libraries, but doesn't output these paths with -print-search-dirs Stage 2 ld is build using mixed paths from stage 1 gcc and the environment and tries to link against /lib libraries which apparently causes it to go nuts since everything it is built with is trying for /tools/lib or the recursive loop is libtool flip flopping between linking to /lib then to /tools/lib without making up it's mind. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #13 from oblivian at users dot sourceforge dot net 2008-04-01 11:51 --- (In reply to comment #12) > I think there are two bugs. One is the infinite loop, and H.J.'s patch is > "masking" it by patching gcc/exec-tool.in (which is why I'd prefer to have the > "masking" in ld/Makefile.am). The other is yours, which does not have > anything > to do with the infinite loop AFAICS. > I too have an infinite loop at stage 2 "gcc" which is the linker calling itself recursively, but as you can see from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35451, I've been tracing the route of the problem. I agree that the patch is "masking" the problem, but I still think it's a change to gcc that is causing binutils breakage. This may need to be fixed in binutils, but right now I need to figure out what changed in gcc. I did forget to mention the following last night as well... I ran a bootstrap with H.J's patch and it compiles through, but is pulling host libraries. I also ran a profiledbootstrap with H.J.'s patch and it can't find newer gcov_ symbols since it appears to no longer be linking with the latest 4.3.0 libraries and trying against older 4.1.2 gcc libraries. After some stuff I've done this morning, I think it is most definitely related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 and the search path cleanup on the 4.3.0 branch. I applied the patch as a test, and now I get a /tools/usr/lib directory in the sys_lib_search_path_dirs of my binutils libtool files BEFORE the standard /lib /usr/lib. I think to fix both problems someone needs to describe the "correct" way of providing the retargeted search paths to the binutils configure scripts for stage 2 and beyond. And sysroot is just broken for this at this point, I went through multiple iterations of sysroot trials with no success. I tried adding BOOT_LDFLAGS=-B/tools/usr/lib -B/tools/lib to and passing BOOT_CFLAGS with the same as well and they don't make it to the binutils program configure scripts. Any insight is appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #15 from oblivian at users dot sourceforge dot net 2008-04-01 11:57 --- In fact the more I think about it, the search path clean up is what has definitely got to be killing this build. The binutils configure scripts rely on the retargeted search paths to come from the previous stage gcc, which have now been removed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #17 from oblivian at users dot sourceforge dot net 2008-04-01 12:14 --- I understand the difference now, and thanks. Still not sure why I can make it through the whole host bootstrap phase without his patch though. Maybe a 4.4 specific change issue? Let me know if you open a second bug on my issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #19 from oblivian at users dot sourceforge dot net 2008-04-01 12:40 --- (In reply to comment #18) > Created an attachment (id=15402) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15402&action=view) [edit] > my version of H.J.'s patch > > I think this is the right way to do it, more or less. > > Can anyone test it? (I don't have binutils checked out right now...) > > You have to run autoconf too. > Yeah I'll apply it now, hold on for about 4 hours. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #21 from oblivian at users dot sourceforge dot net 2008-04-01 13:53 --- (In reply to comment #20) > if it reaches the end of ld compilation in stage2, that's already enough. > (and > less than 4 hours). > Sorry, but for me to test it I have to wait until the pass 2 compiler, since that's the one that breaks. So I can at least tell you it didn't break the pass 1 compiler in < 4 hours. Of course I've already had to restart the build 5 times to get my scripts to run autoconf in the gcc subdirectory so we'll see how long it takes to get through pass 1 (i just restarted the build hopefully for the last time). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #22 from oblivian at users dot sourceforge dot net 2008-04-01 15:30 --- Doesn't work. In my setup enable-fast-install is not getting set, but the prev-ld is generating an lt-ld-new, so it assumes it should use the current ld instead of the prev-ld binary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #24 from oblivian at users dot sourceforge dot net 2008-04-01 15:39 --- (In reply to comment #23) > and if you modify collect-ld manually to set it to yes? > Sure that works, but doesn't that defeat the purpose? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #25 from oblivian at users dot sourceforge dot net 2008-04-01 15:41 --- (In reply to comment #24) > (In reply to comment #23) > > and if you modify collect-ld manually to set it to yes? > > > Sure that works, but doesn't that defeat the purpose? :) > How about changing it to != no? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #31 from oblivian at users dot sourceforge dot net 2008-04-01 16:44 --- (In reply to comment #30) > Created an attachment (id=15409) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15409&action=view) [edit] > new patch > > @Ralf: yes, I understood that (I just wanted to understand if the failure was > just that my way of setting enable_fast_install was too hacky). > > This patch should work. It creates a good collect-ld for me. > Nope /build/scripts/tools/toolchain-pass-2/build/gcc/../prev-binutils/nm-new: cannot execute: No such file or directory No symbols seen -- broken or mis-installed nm? This was in libgcc before the stage 1 directories are moved to prev- -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #32 from oblivian at users dot sourceforge dot net 2008-04-01
18:55 ---
(In reply to comment #30)
> This patch should work. It creates a good collect-ld for me.
>
How about a simple change without the whole fast-install patch.
if test -x $scriptdir/../prev-$dir/$prog; then
exec $scriptdir/../prev-$dir/$prog ${1+"$@"}
else
exec $scriptdir/../$dir/$prog ${1+"$@"}
fi
Thats it. Just prefer the use of the previous stage utilities. No worrying
about the state of the current stage utilities. Unless I'm missing something
(e.g. internal gcc reasons) doesn't this meet the primary requirement
bootstrapping the compiler (i.e. building the current stage with the previous)
and prevents mixing partially finished utilities inside the stage?
It also keeps the exec-tool.in script clean from specialized code depending on
the target it's being run as (well except for the invoke case statement at the
top).
I'm currently through stage 2 with this simple change to exec-tool.in.
As long as this doesn't break any rules, it should allow the sysroot problems I
had to disappear as well, which will fix my prefix issue as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #33 from oblivian at users dot sourceforge dot net 2008-04-01 19:04 --- (In reply to comment #32) > (In reply to comment #30) > > This patch should work. It creates a good collect-ld for me. > > > > How about a simple change without the whole fast-install patch. > How about not, since intl configure now gives me this: xgcc: ldgram.o: No such file or directory xgcc: ldlex.o: No such file or directory xgcc: lexsup.o: No such file or directory xgcc: ldlang.o: No such file or directory xgcc: mri.o: No such file or directory xgcc: ldctor.o: No such file or directory xgcc: ldmain.o: No such file or directory xgcc: ldwrite.o: No such file or directory xgcc: ldexp.o: No such file or directory xgcc: ldemul.o: No such file or directory xgcc: ldver.o: No such file or directory xgcc: ldmisc.o: No such file or directory xgcc: ldfile.o: No such file or directory xgcc: ldcref.o: No such file or directory xgcc: sha1.o: No such file or directory xgcc: eelf_i386.o: No such file or directory xgcc: ei386linux.o: No such file or directory xgcc: ../bfd/.libs/libbfd.so: No such file or directory xgcc: ../libiberty/libiberty.a: No such file or directory Oh well. I thought it would work -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap
--- Comment #34 from oblivian at users dot sourceforge dot net 2008-04-01 19:04 --- Sorry make that stage 3 intl gives me the above -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #37 from oblivian at users dot sourceforge dot net 2008-04-02 13:47 --- (In reply to comment #35) > the infinite loop is fixed, don't know if the second bug remains. > Yes and no, It fixes the compilation so that ld no longer gets into a loop, but the installed compiler is still not working due to the missing search paths. This bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35532 explored the issue of using sysroot for native builds and it appears the consensus is not to support retargeted compilers anymore for native builds, and that the sysroot framework should be used even though some people are still stating that it is for cross compiling only. I'll be opening a new bug on the sysroot problems I'm having with 4.3 since it appears no one has tried a combined gcc + binutils bootstrap with sysroot (or at least I can't find a bug on it in gcc bugzilla). Thanks for all the help. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #39 from oblivian at users dot sourceforge dot net 2008-04-02 14:19 --- Created an attachment (id=15413) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15413&action=view) Optional way to fix ld relink problems Just for completeness, here is the fix the Ralf was suggesting. I tried this out and it seems to work as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
[Bug bootstrap/35804] New: Bootstrap of combined gcc + binutils, with --enable-shared, with sysroot fails
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
--- 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
--- 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 (0xb7e9) /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
--- 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
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
--- 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
--- 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 libstdc++/35816] New: libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins
When compiling a combined gcc + g++ + binutils, the configure script for the libstdc++ library is using the host g++ rather than the last stage g++ for determining atomic builtin support status. While I probably need to compile the toolchain with CXXFLAGS=-march=i486, from what I've read, to enable support for atomic builtins in the compiler, I did not. This resulted in a target g++ that did not support atomic builtins and a libstdc++ that expected the compiler did because it got the value from checking the host g++ rather than the final bootstrap stage g++. The configure parameters were: --prefix=/$(TOOLS_DIR)/usr \ --with-sysroot=/$(TOOLS_DIR) \ --with-pic \ --enable-shared \ --enable-clocale=gnu \ --enable-threads=posix \ --enable-__cxa_atexit \ --enable-languages=c,c++ \ --enable-checking=release \ --disable-werror \ --enable-stage1-checking \ --enable-bootstrap -- Summary: libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oblivian at users dot sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug libstdc++/35816] libstdc++ built during bootstrap is pulling in host g++ support for atomic builtins
--- Comment #1 from oblivian at users dot sourceforge dot net 2008-04-03 17:34 --- After looking back at my 4.2.3 build logs. The above is somewhat incorrect. In 4.2.3, the pass 2 toolchain build of libstdc++ correctly checked the target g++ rather than the host and reported that it would not use atomic builtins. It appears that this has changed in 4.3.0 or is an artifact of using sysroot (which should not look at the host g++ for configuration options). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug libstdc++/35816] libstdc++ build during bootstrap is optimizing away atomic builtin check
--- Comment #2 from oblivian at users dot sourceforge dot net 2008-04-03 20:45 --- Ok so the gcc/g++ i build has optimization on by default. The configuration scripts don't seem to take this into account and the call to CXX for the atomic check is optimizing away the check in the output assembly code; thus, the grep for __sync_fetch_and_add fails and does not turn off atomic builtins. the following is right before the code generation in the configure file # Fake what AC_TRY_COMPILE does. XXX Look at redoing this new-style. The check probably needs to also take into account optimization so that the check for __sync_fetch_and_add can not be removed regardless of optimization flags. To revert to 4.2.3 behavior I inserted a -O0 in the ac_compile command for the check. -- oblivian at users dot sourceforge dot net changed: What|Removed |Added Summary|libstdc++ built during |libstdc++ build during |bootstrap is pulling in host|bootstrap is optimizing away |g++ support for atomic |atomic builtin check |builtins| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35816
[Bug bootstrap/35752] [4.3/4.4 Regression]: Combined gcc + binutils source tree doesn't bootstrap with --enable-shared
--- Comment #57 from oblivian at users dot sourceforge dot net 2008-04-25 15:00 --- I don't have permissions to change the status, but it looks like bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33503 is a dup or at least related if someone wants to clean it up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752
