Summary: | Suggestion to simplify cross compiler setup for distcc in a hetrogenous network environment | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew de Quincey <adq_dvb> |
Component: | [OLD] Development | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED LATER | ||
Severity: | enhancement | CC: | kumba, radek |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
gcc 3.4.4 patch to disable libgcc
Minimised patch to disabled libgcc |
Description
Andrew de Quincey
2005-04-04 10:38:07 UTC
I'm not sure why this is assigned to me, perhaps the portage or crossdev team would be a better idea? ...are you sure you can compile gcc with c++ support without compiling glibc first? Maybe I just didn't understand your terminology... yeah - I'm doing this on three difference architectures here (x86, amd64, and ppc). Actually, what it does is disable libgcc, which in turn means it doesn't need glibc. Attached is my latest patch to gcc 3.4.4 to disable libgcc. Created attachment 70554 [details, diff]
gcc 3.4.4 patch to disable libgcc
one of the points to forcing a second stage gcc is to also properly build threading support gcc cannot build thread support properly if it does not have libc headers Does gcc need threading support compiled into the compilers themselves? This is _only_ for distcc cross compilation - where it takes a .c/.cc file and compiles it into a .o file... I wouldn't have expected threading to be a part of that process. Certainly at the link stage I can see the requirement, but linking is not done on the cross compiling slaves (which is where this special GCC runs). Its done on the machine generating the cross compile tasks, which will have a full gcc install including glibc/libgcc etc etc. Actually, if you look at how the "nocxx" flag works, it doesn't build libgcc/require glibc either. Does threading work fine with a "nocxx"-built gcc? All this patch does is the same for g++. a stage1 cross-compiler builds with both --without-headers and --without-thread a normal compiler with USE=nocxx builds both with headers and with threads Er yeah, but I don't remember saying I was disabling building stage2 anywhere? The patch disables libgcc yes, but thats the only change. There are no other changes to my ebuild (apart from applying the patch). I certainly don't supply --without-headers and --without-thread anywhere. The only change to the ebuild is to add a line to apply the patch. i was replying to your nocxx comment a USE=nocxx compiler requires glibc/headers Ah - sorry - I was confused. Actually, reading back to my original comment, I see I do say I was using stage1. Sorry, its been months since I added this and I'd forgotten everything about it. OK, sorry, I've changed the way I build things since I originally submitted this bug - I didn't realise it was so old. Here goes with what I do now (I no longer use crosstool to create the compilers). To cross compile things, I copy the directories /usr/portage/sys-devel/gcc and /usr/portage/sys-devel/binutils to /usr/local/portage/cross-powerpc-unknown-linux-gnu Then I patch /usr/local/portage/cross-powerpc-unknown-linux-gnu/gcc-3.4.4-r1.ebuild and add: epatch "${FILESDIR}"/3.4.4/gcc-3.4.4-nolibgcc.patch where it says "fix cross compiling" Then I emerge cross-powerpc-unknown-linux-gnu/gcc. It builds gcc + binutils (and g++) The use flags for that gcc are: [ebuild R ] cross-powerpc-unknown-linux-gnu/gcc-3.4.4-r1 (-altivec) -bootstrap -boundschecking -build -fortran -gcj -gtk -hardened -ip28 (-multilib) -multislot (-n32) (-n64) +nls -nocxx -nopie -nossp -objc -static -vanilla 0 kB [1] once its built, the cross compiler reports: powerpc-unknown-linux-gnu-gcc -v Reading specs from /usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/specs Configured with: /var/tmp/portage/gcc-3.4.4-r1/work/gcc-3.4.4/configure --prefix=/usr --bindir=/usr/powerpc-unknown-linux-gnu/gcc-bin/3.4.4 --includedir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include --datadir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4 --mandir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/man --infodir=/usr/share/gcc-data/powerpc-unknown-linux-gnu/3.4.4/info --with-gxx-include-dir=/usr/lib/gcc/powerpc-unknown-linux-gnu/3.4.4/include/g++-v3 --host=x86_64-pc-linux-gnu --target=powerpc-unknown-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --enable-nls --without-included-gettext --with-system-zlib --disable-checking --disable-werror --disable-libunwind-exceptions --disable-multilib --disable-libgcj --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu Thread model: posix gcc version 3.4.4 (Gentoo 3.4.4-r1, ssp-3.4.4-1.0, pie-8.7.8) I don't need kernel header files (installed on the cross-compiler) since the preprocessing stage is done already by the machine distributing distcc tasks. Perhaps this is only suited to environments where all machines run the same glibc/kernel? Either way, this setup has been working for me for a long time with no problems. all in all, this is a pretty intrusive patch anyway it can be minimized ? Created attachment 70650 [details, diff]
Minimised patch to disabled libgcc
How about this? It greatly decreases the number of lines changed... I hope this
is what you were meaning.
yes, that's what i meant, thanks Do we plan on adding this? Also, calling it "distcc" might be misleading if I understand this correctly. at this point, no, i dont plan on adding it there is no easy way to integrate this limited behavior so that it only happens when a user specifically wants it |