[Bug bootstrap/35451] New: stage2 bootstrap xgcc infinite loop

[Bug bootstrap/35451] New: stage2 bootstrap xgcc infinite loop

[oblivian at users dot sourceforge dot net]

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|major                       |normal


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

[Bug bootstrap/35451] stage2 bootstrap xgcc infinite loop

[oblivian at users dot sourceforge dot net]

------- 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

[oblivian at users dot sourceforge dot net]

------- 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/35451] stage2 bootstrap xgcc infinite loop

[rwild at gcc dot gnu dot org]

------- Comment #3 from rwild at gcc dot gnu dot org  2008-03-31 17:07 -------
Is this the same as bug 35752?


-- 

rwild at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rwild at gcc dot gnu dot org


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

[Bug bootstrap/35451] stage2 bootstrap xgcc infinite loop

[hjl dot tools at gmail dot com]

------- Comment #4 from hjl dot tools at gmail dot com  2008-03-31 17:44 -------


*** This bug has been marked as a duplicate of 35752 ***


-- 

hjl dot tools at gmail dot com changed:

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


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