uClibc-0.9.29 with glibc host system, compile time problem

For Junk Mail junk_mail at irishbroadband.net
Thu Dec 20 04:14:34 PST 2007


On Mon, 2007-12-17 at 23:04 -0600, Kevin Day wrote: 
> I am still using the old non-embryo compile time method, so you may
> have avoided this problem; however, I am presenting this as a note for
> anybody suffering from this problem.
> 
> The problem is simply, gcc (4.1.2 is what I am working with) does not
> want to compile properly, in fact it segfaults while under
> uClibc-0.9.29, before I can reach the adjust toolchain stage.
> 
> This means that everything is building in  some way that could be
> thought of as "infected by glibc".
> 
> No matter how I compile it, gcc finds some spot to segfault during the
> build process.
> 
> I am testing this on two very similar architectures in parallel (both
> are 64-bit AMDs running in 32-bit mode), with one under an existing
> uClibc build and another under a glibc build.
> 
> The uClibc host shows no problems whatsoever compiling the toolchain.
> 
> Changing ONLY the uClibc to 0.9.28.3, with as similar uClibc configs
> as I can possibly get on the glibc host, the toolchain compiles
> cleanly as well.
> 
> The only time there is every any problem building a temporary
> toolchain from a glibc host with uClibc-0.9.29.
> 
> I then experimented with building the first stage under
> uClibc-0.9.28.3, which works on the host, and then after the first
> stage is completely installed and the adjust toolchain occurs, compile
> uClibc-0.9.29.
> 
> This seems to have worked.
> 
> Summary:
> First Stage = uClibc-0.9.28.3 when under a glibc host
> Second Stage = uClibc-0.9.29, and now things built against 0.9.29
> should not segfault, such as gcc and binutils.

I'm taking the view that the uClibc book is currently an invitation to
experiment with the process. Chapter 5 has to be, for it does not offer
separate instructions for glibc --> uclibc, and uclibc --> uclibc
builds. I have been experimenting. I cannot replicate your segfaults. As
you know, I have your system built here as well, and the older, separate
build of binutils and gcc is certainly more reliable. 

The single biggest issue here was the fixincludes script being run in
the embryo toolchain (when everything smelled of glibc) leading to
includes errors after the cocoon stage. When I don't run it, the cocoon
compile barfs configuring libstdc++-v3 well into the cocoon toolchain.
I'm circling that one now. 

Declan.
-- 
For Junk Mail <junk_mail at irishbroadband.net>




More information about the hlfs-dev mailing list