On Sunday, May 03, 2015 11:59:08 PM Walter Dnes wrote: > On Sun, May 03, 2015 at 02:57:46PM -0400, Fernando Rodriguez wrote > > > Some packages do custom preprocessing and other weird things during > > the build process that cause problems with pump mode since it caches > > copies of the unmodified headers. If you're lucky it just fails (and > > usually falls back on compiling locally), if you're not then it may > > succeed and you'll get runtime bugs. I haven't find a package yet > > that fails without pump mode as long as your CFLAGS are set properly. > > Seamonkey fails during the build process. Two tries, and the build > log was 74,046 bytes each time. I have an Intel x86_64 as the host, and > an Atom i686 (32-bit only) as the client. Given your description, I may > drop "pump" altogether from my "xmerge" script. I'll unmerge > seamonkey-bin, and try distcc-building seamonkey from source, without > "pump", Monday when I have more time. Here are a few lines from the > failed build log, using "pump"... > > Executing: gcc -o nsinstall_real -march=atom -mtune=atom -fstack-protector - pipe -mno-avx -DXP_UNIX -MD -MP -MF .deps/nsinstall_real.pp -O2 -DUNICODE - D_UNICODE -Wl,-O1 -Wl,--as-needed host_nsinstall.o host_pathsub.o > > /usr/lib/gcc/i686-pc-linux-gnu/4.8.4/../../../../i686-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `host_nsinstall.o' is incompatible with i386 output > > /usr/lib/gcc/i686-pc-linux-gnu/4.8.4/../../../../i686-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `host_pathsub.o' is incompatible with i386 output > > /usr/lib/gcc/i686-pc-linux-gnu/4.8.4/../../../../i686-pc-linux-gnu/bin/ld: host_nsinstall.o: file class ELFCLASS64 incompatible with ELFCLASS32 > > /usr/lib/gcc/i686-pc-linux-gnu/4.8.4/../../../../i686-pc-linux-gnu/bin/ld: final link failed: File in wrong format > >
The error on the link that you posted looks like cause by pump mode, this one I'm not so sure. It looks like you're not using the cross compiler on the host as it would not generate 64 bit code. Did you add -m32 to your CFLAGS on the client box? Also you may need to set the custom-cflags use flag. Can you verify that it is using the cross compiler on the host? I'm not sure exactly what the gentoo recommended distcc/cross compile setup but if you do it like I suggested on your other thread (using the host 64bit compiler) it should work. Look at the links you got under /usr/lib/distcc/bin. All you need to do is create scripts on the host with the exact same names and have them execute the compiler that you want with the options you want (I just have it execute the 64bit compiler with -m32). Then make sure that distccd (on host) finds them before the actual compiler by putting it in the PATH environment variable before anything else. For that you may need to modify the init script or unit file if using systemd or just start distccd manually. A simpler hack is to just delete the c++, cc, gcc, and g++ symlinks from the /usr/lib/distcc/bin directory. That will force distcc to only trap the compiler invocations that use the full compiler name and end up using the cross compiler in the host, but if you do this you may end up compiling more stuff locally. -- Fernando Rodriguez
