Am 16.04.2013 15:46, schrieb Matthew Gretton-Dann: > On 16/04/13 14:08, Matthias Klose wrote: >> Am 16.04.2013 11:49, schrieb Matthew Gretton-Dann: >>> The issues I encountered were: >>> * Its hard to get a machine running in hard-float to bootstrap a >>> soft-float >>> compiler and vice-versa. >> >> hmm, why? >> >> when using precise or quantal as the build environment, then having these >> packages installed should be good enough: >> >> libc6-dev-armhf [armel], libc6-dev-armel [armhf] >> binutils >> g++-multilib >> >> Although I still have a local patch to support the multilib configuration: >> >> http://anonscm.debian.org/viewvc/gcccvs/branches/sid/gcc-4.8/debian/patches/arm-multilib-defaults.diff?revision=6640&view=markup >> > > I honestly don't know what the issue is - except that when I try to bootstrap > a > vanilla FSF GCC arm-none-linux-gnueabi with the initial host compiler as > arm-none-linux-gnueabihf I get failures during libraries builds in stage 1. > > Also given that we try to build vanilla compilers, and so for 4.6 & 4.7 that > requires fiddling with links in /usr/lib and /usr/include to point into the > multiarch stuff, doing this in a chroot is safer than on the main system.
this is not true. afaics all the active gcc linaro releases do have the multiarch patches merged from upstream. So knowing the root cause would be better than tampering with the links. Matthias _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
