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. Greg #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 ... Greg On 26/12/2012 19:24, Bruce Dubbs wrote: > On Wed, Dec 26, 2012 at 2:44 PM, Gregory Nietsky <gregniet...@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 -- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
