This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
The goal is to release a build system which allows customers to easily develop applications for our SBC's distribution.
I went the cross compiler route because I am somewhat familiar with building cross-gcc's for different architectures (Coldfire and HCS12) so I figured building one for our SBC's would be easy and useful.
I now see that I didn't know what I was talking about.
Thanks to crossgcc, it's really not that bad. But adapting a cross toolchain to be binary compatible with pre-existing natively built library binaries can be a little tricky.
Since I'm use to building on different architectures, I have no experience with the chroot route, but maybe that's best........I'm certainly open to suggestions. Do you know of any good howto's out there?
For Debian (and Debian-derived distros that provide apt repositories), it is made fairly simple by debootstrap. The easiest thing is probably to set up a Debian (or Ubuntu, etc.) staging box, take a quick look at the debootstrap manpage and what Google turns up for "debootstrap howto", and use it to generate a starting chroot. Then strip it down as you like and tarball it up; unpack it on any x86 Linux box with a 2.6 or late 2.4 kernel, mount procfs and friends, and preface your top-level make with the appropriate chroot incantation.
My only problem with it is can I do it entirely from a Makefile? Will my IDE's still work if I chroot while building from them?
If you Google a bit you can probably find a code snippet to put at the top of your Makefile that will check whether it is running under your chroot and, if not, sudo chroot /path/to/chroot su $$USER /bin/sh -c $(MAKE), etc. Or you could go the whole hog with scratchbox. If your IDE has a gdb front end and you want to hook it to a gdb stub on the target, that's also feasible, although it's been a while since I went to that much trouble; if I am setting up a Debian-based embedded system and my dev board has enough memory, I tend to NFS mount a native development environment (nfsroot or chroot) and run gdb locally.
But again, your requirements may well fit the cross-compile paradigm better, in which case the easiest thing may be to add some Debian-aware download/unpack magic to crosstool and treat it as a moderately forked glibc upstream tarball. Crosstool's configure/make sequence should work once you have run "debian/rules patch" or something like that; apt-get source glibc and look inside debian/rules, which is just a makefile with some target naming conventions.
Cheers, - Michael
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |