Re: [Patches] cross compiling eglibc

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

On Tue, 4 Sep 2012, Christer Solskogen wrote:

> Hi again.
> 
> I'm in the process of creating a new how to for creating a cross
> compiler (with (e)glibc) with the hope of replacing the existing doc
> that is in the trunk. I'm almost finished, but today I figured a

Steve, ping again about your changes to improve option group configuration 
and update this documentation.  As I said on 3 April, I think they were 
just waiting for properly formatted GNU-style ChangeLog entries 
<http://www.eglibc.org/archives/patches/msg01049.html>.

> shortcut that I wonder if is ok or not. Eglibc (and glibc as well I
> suppose) is dependent on libgcc_s and libgcc_eh. Those get built by
> gcc when building the final gcc. But, is it ok to just create symlinks
> from libgcc.a to those files before building eglibc? If yes, the way
> to create a cross compiler will be this easy: binutils -> gcc-core ->
> linux headers -> eglibc -> gcc.

Creating such symlinks is incorrect.  After my changes that went in just 
after 2.16 branched, it should be possible to build glibc using a 
static-only GCC; there should be no dependence of the build on libgcc_s 
and libgcc_eh.  But you need two libgcc patches of mine that only went in 
after GCC 4.7 branched in order for the glibc you get to be the same as 
you'd get when building with a full GCC (using shared libraries and with a 
previously built glibc).  So before GCC 4.8 you still need the three 
compilers to get the same results as you would get from a convergent 
iteration of building alternating GCC and glibc: the GCC providing the 
libgcc used when building glibc has itself to have been built with shared 
libraries enabled (so the correct symbols are hidden) and without 
inhibit_libc (so crt*.o are correctly configured for exception handling).

If you wish to discuss further improvements along the lines Roland 
described in <http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>, 
libc-alpha and the GCC lists would be the right place.  In general we want 
to merge cross-compilation improvements (and other changes) into glibc and 
not make further local changes in that area in EGLIBC - or any local 
changes not necessarily interlinked with existing EGLIBC-local features.  
(Similarly, improvements, directly in glibc, to glibc's install.texi would 
be better than more EGLIBC-specific documentation, for anything about 
installation that does not need to be EGLIBC-specific.)

-- 
Joseph S. Myers
joseph@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches