26.06.2011 01:37, KP Kirchdoerfer пишет: > Am Sonntag, 26. Juni 2011, 00:05:05 schrieb Andrew: >> 26.06.2011 00:54, KP Kirchdoerfer пишет: >>> Am Samstag, 25. Juni 2011, 23:41:24 schrieb Andrew: >>>> 25.06.2011 23:19, KP Kirchdoerfer пишет: >>>>> Am Samstag, 25. Juni 2011, 21:57:35 schrieb Andrew: >>>>>> 25.06.2011 22:45, KP Kirchdoerfer пишет: >>>>>>> I have installed binutils-2.21.0.20110327-2ubuntu3. >>>>>> I still use 2.20 - and 3 days ago rebuild was successful. So trouble >>>>>> in host binutils. >>>>>> >>>>>>> In our recent buildenv we do have binutils-2.21, committed by David >>>>>>> due to pb's with host gcc. >>>>>>> Why is should binutils leak into buildenv now, when David had to >>>>>>> update binutils to work with his gcc? >>>>>>> >>>>>>> I guess the error is somewhere else/before...?? >>>>>>> >>>>>>> kp >>>>>> At first look error is on refreshing uClibc config (make oldconfig or >>>>>> something like this) at first stages of toolchain reassembly, wheu >>>>>> host compiler and binutils are used. >>>>> Agree; >>>>> unfortunately I have no time for deep investigations these days. I'm >>>>> running out of time preparing a presentation to finish my job-training. >>>>> So I can only help with doing compilations in the background and >>>>> reporting back. >>>>> >>>>> kp >>>> As I understanded from mailing lists, wrong .size directives in crtn.S >>>> are really obsolete and can be removed. I added patching, and now I'm >>>> running rebuild on my PC. >>> Thx Andrew. >>> >>> At least buildenv compiles now: > Too early..:( > > Now I run into: > checking whether assembler supports --noexecstack option... yes > checking for none-pc-linux-uclibc-ar... /opt/buildtool-test/staging/bin/i486- > pc-linux-uclibc-ar > checking for BSD-compatible nm... /opt/buildtool-test/staging/bin/i486-pc- > linux-uclibc-nm > checking for a sed that does not truncate output... /bin/sed > checking for ld used by /opt/buildtool-test/source/buildenv/gcc-4.4.5- > final/./prev-gcc/xgcc -B/opt/buildtool-test/source/buildenv/gcc-4.4.5- > final/./prev-gcc/ -B/opt/buildtool-test/staging/i486-pc-linux-uclibc/bin/ - > std=gnu99... /opt/buildtool-test/staging/bin/i486-pc-linux-uclibc-ld > checking if the linker (/opt/buildtool-test/staging/bin/i486-pc-linux-uclibc- > ld) is GNU ld... yes > checking for /opt/buildtool-test/staging/bin/i486-pc-linux-uclibc-ld option to > reload object files... -r > checking whether ln -s works... yes > checking how to recognize dependent libraries... pass_all > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking how to run the C++ preprocessor... /lib/cpp > configure: error: C++ preprocessor "/lib/cpp" fails sanity check > See `config.log' for more details. > make[3]: *** [configure-stage2-gmp] Error 1 > make[3]: Leaving directory `/opt/buildtool-test/source/buildenv/gcc-4.4.5- > final' > make[2]: *** [stage2-bubble] Error 2 > make[2]: Leaving directory `/opt/buildtool-test/source/buildenv/gcc-4.4.5- > final' > make[1]: *** [all] Error 2 > make[1]: Leaving directory `/opt/buildtool-test/source/buildenv/gcc-4.4.5- > final' > make: *** [/opt/buildtool-test/source/buildenv/gcc-4.4.5-final/.compiled] > Fehler 2 > > kp Hmm, this is fresh trouble, it isn't related with patches (at least, my copy was rebuilded from scratch successfully). It looks like trouble with included libgmp, more detailed info can be obtained from gcc-4.4.5-final/gmp/config.log or gcc-4.4.5-final/prev-gmp/config.log
------------------------------------------------------------------------------ All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
