[lfs-dev] GlibC 2.17 / GCC 2.7.3 [git]

Gregory Nietsky gregnietsky at gmail.com
Thu Dec 27 03:49:47 PST 2012

Bruce Dubbs  Pleasure is all mine

of course 2.7.3 is 4.7.3 stupid typo.

Did a complete rebuild and have one strange problem with udev-182
udevd barfs with undefined reference to mq_getattr ... adding a -lrt to
udevd_LDADD in  Makefile.am [automake/autoreconf] sorts this out posting 
this here in case someone needs to stumble upon it.

the switch to 4.8 has me a little concerned indeed, i have started 
building bootstrap compilers
with lang=c,c++ statically then building a multi arch c only to get 
libgcc for arches [m32/m32x/m64/....]
then build it all "shared" so the bootstrap process is as follows

one plus for 4.8 is it will support aarch64 [ the AMD 64bit ive put in a 
request for a dev board and should get that soon].also note
that the --with-multilb-list/--with-abi options bellow for x86 are not 
in 4.7 mainline and will also be included in 4.8 im using
hjl/x32/gcc-4_7-branch branch.hjl/x32/gcc-4_7-branch

guess its as good a time as any to start the ball rolling and get some 
testing/discussion done if you thinking about 4.8 ill put some sweat 
into it too
was going to hold back until i got my toys but thats what the silly 
season is for ...

it may also be an idea to mention the libjava/classpath options to gcc 
to allow latter possible bootstraping of icedtea [openjdk]
... --enable-java-home --with-jvm-root-dir=/usr/lib*/jvm/gcj-jdk
link gjar to jar [ala gcc ->cc]

all you need now to build a JDK is icedtea [it has dependancies X/....] 
,apache ant and the ECJ jar file from eclipse.


#step 0
create /dist/root/.... with the appropriate /usr/include linux asm* bits 
and glibc [a virgin clean root]

#Step 1 [native is x86_64 i do use a cross build to build a rootfs]
../configure --libdir=/usr/lib64 --prefix=/usr --sysconfdir=/etc 
--mandir=/usr/share/man --infodir=/usr/share/info --localstatedir=/var 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu --with-build-sysroot=/dist/root/x86_64 
--disable-shared --without-lto --disable-bootstrap 
--enable-languages=c,c++ --with-sysroot=/ --disable-libmudflap 
--disable-libswsp --disable-libgomp --with-system-zlib --without-ppl 
--without-cloog LDFLAGS=-static --enable-multilib 
--with-multilib-list=m64 --with-abi=64
make LDFLAGS=-static

this gives me a native gcc that is statically linked this goes into the 
bootstrap with other utils bison/sed/gawk/.... all statically linked

#Step 2 Chroot [perhaps boot depending on the target] to the static chain
Build GLIBC with the above

#3 Build the multi arch C bits this is to land up with libgcc* this note 
we cant add c++ here as we have no GLIBC for the arch see 4
../configure --libdir=/usr/lib64 --prefix=/usr --sysconfdir=/etc 
--mandir=/usr/share/man --infodir=/usr/share/info --localstatedir=/var 
--build=x86_64-linux-gnu --host=x86_64-linux-gnu 
--target=x86_64-linux-gnu --with-build-sysroot=/dist/root/x86_64 
--enable-languages=c --without-ppl --without-cloog --without-lto 
--disable-bootstrap --disable-libitm --disable-shared 
--disable-libmudflap --disable-libswsp --disable-libssp 
--disable-libquadmath --disable-libgomp --enable-multilib 
--with-multilib-list=mx32,m64,m32 --with-abi=64

#4 Build glibc for each arch and put the /lib* /lib* bits in place
We need GLIBC for each arch to proceed any further

#5 Build GCC with at least c/c++ to suite taste
....... --enable-multilib --with-multilib-list=mx32,m64,m32 --with-abi=64
this will build a complete chain that can build i386/x86_64/x86_x32. im 
replacing low end low mem 32bit systems
with a x86_x32 build. some problems still with support for x32 things 
like QT [KDE], mplayer/ffmpeg.... [some accelerated codecs].
overall i see a advantage in it compared to 32bit.

having the C++ from step 1 should allow building of step 3 / 5. i 
suspect i may need to build a shared version of step 3 with c++ as step 
5 and have the final gcc cooked in a step 6.

besides this additional complexity when cross/multi building all that 
should change is making sure c and c++ are included in the bootstrap of 
a system.

hey besides this patch was done by a googalite and we all know that 
google knows everything ...


On 26/12/2012 19:24, Bruce Dubbs wrote:
> On Wed, Dec 26, 2012 at 2:44 PM, Gregory Nietsky <gregnietsky at gmail.com> wrote:
>> Just like to report that all works as expected with minimal patching
>> Thanks for the info.  If gcc-4.8.0 is due out in a month, we may want
>> to hold off on gcc-4.7.3 and go directly there.  I may pull a
>> pre-release version to check it out.  I'd expect potential problems
>> with a c -> c++ conversion.
>>    -- Bruce

More information about the lfs-dev mailing list