On 10/13/08, Dave Bender <[EMAIL PROTECTED]> wrote: > A tool for building cross compilers is actually quite useful (I currently > use crossdev).
IMO, it's not _that_ useful. The problem is that a lot of the development boards I've come accross ship their own "customized" uclibc on the rootfs. If you link your application against a different libc (the one contrarius built for you), it generally seg-faults when you come to run it on the device. Devices with GNU-EABI based glibc seem to be much better, but I've still seen some issues. The only use I can see in rolling your own toolchain is if you want to generate your own rootfs with the toolchain's libc. As someone commented before, most of the ebuilds in portage don't cross-compile properly, so doing a complete rootfs is pretty painful. OpenEmbedded is a much better option for doing that. Personally I _hate_ OpenEmbedded, but I have to admit, it does get the job done. There's also the probem of maintaining the gcc patch set to make it actually build as a cross-compiler. It's hard work and IMO not worth it. Almost everyone I know now uses the CodeSourcery toolchains, certainly for arm and I use it for other architectures too. Perhaps it would be better to add packages for the CodeSourcery cross-toolchains rather than try to maintain our own toolchain-generator? Or perhaps add packages for crosstool? I.e. let someone else have the headache. > The other possible intended audience are developers who may want to cross > compile on an x86_64 host for 32 bit based hosts. As Ciaran pointed out, > this is largely a useless effort, since people use 32bit chroots for this > anyway. Why chroot exactly? I "cross-compile" for 32-bit all the time as my code depends on some binary-only 32-bit (OpenGL ES) libraries. I find passing -m32 to gcc works every time (as long as you have app-emulation/emul-linux-x86-* installed) :-) Cheers, Tom _______________________________________________ paludis-user mailing list [email protected] http://lists.pioto.org/mailman/listinfo/paludis-user
