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] |
Trevor, All, On Wednesday 16 November 2011 17:16:08 Trevor Woerner wrote: > I can appreciate you have your reasons for not liking option 1, but > from my point of view: for what other purpose does the cross-compiler > exist other than to create a cross-filesystem? It's not like I'm going > to then use the cross-compiler to cross-compile random bits and pieces > which aren't going to be put on the image anyway, so preserving its > integrity is irrelevant to me. Besides, for all the effort and > trail-and-error it would save me, I'd rather just rebuild the cross > toolchain and have multiple copies of it installed on my development > machine if I needed a pristine one or was putting together multiple > images. I'm guessing there are probably other reasons? Yes, a toolchain that is shared betwen many developpers. For example, consider this situation: - 10+ hardware targets, of different architectures (ARM, x86, MIPS...) - 50+ projects - team of 150+ developpers - team dedicated to the tooling (toolchains, build system...) In that situation, you want to ensure all developpers have the same tools for a given tuple {project,target}, but you can't replicate the toolchains for every developpers, or upgrades would be a ultimate burden. Also, you do not want to allow each developper to fiddle with the toolchain, or it would no longer be the same toolchain other developpers are using. So, you do not want the toolchain sysroot to be polluted with what every developer wants to install on his rootfs. Yes, this is a common situation in an industrial context... > I'm assuming, however, to use option 1 I would need to specify the > toolchain's sysroot directory as the --prefix? No, you want to set prefix to the _runtime_ prefix, probably / or /usr or /usr/local. And you want to use: make DESTDIR=/path/to/staging install. > Won't that mess up the > dynamic loader on the target (although if all libraries are installed > to $SYSROOT/lib and $SYSROOT/usr/lib I'm guessing it'll just work)? The problem will not be, in the common case, with the dynamic linker. ELF headers only list the name of the libraries to load, not their paths, so the dynamic linker will succesfuly find libraries at runtime. The problem will arise when programs will try to load their data, because they were configured to expect everything in (say) /home/foo/blabla/sysroot but this path does not exist at runtime, so they would fail to load: - their ressources (icons, images...) - their dlopen-ed libraries - the libraries in RPATH (RPATH is a beast to deal with, though with a bit of fiddling, it can be made to behave) So what you want to do, is: ./configure --build=build-tuple --host=host-tuple \ --prefix=/usr --enable-foo-bar... make make DESTDIR=/path/to/staging install and repeat for all your packages. Then if you used the sysroot as staging, you'd have to push that to the target rootfs (eg. filesystem image, copy to NFSroot...), but you would endup with lots of cruft: headers, static libs, many other things that makes the sysroot usefull at build time, but are mostly useless at runtime. Then you'd have to clean it up. Basically, about 75% (size wise) of a uClibc sysroot is useless at runtime (32MiB, vs. only 8MiB for all .so files). It's even worse with glibc. With the third alternative, you only have to copy the _required_ files from the sysroot to the staging, by scanning all ELF files from your staging, on fetching the NEEDED files from the sysroot. Crostool-NG installs a program that does just that: tuple-populate Of course, it means you indeed have to pass appropriate CPPFLAGS to point to where your non-sysroot headers are, and proper LDFLAGS to where non- sysroot libraries are, eg.: CPPFLAGS="-I/path/to/staging/usr/include" \ LDFLAGS="-L/path/to/staging/lib -L/path/to/staging/usr/lib" \ ./configure blabla-as-above... Solution two would mean: cp -a $(tuple-gcc --your-cflags-except-sysroot -print-sysroot) \ /path/to/staging ./configure --blabla-as-above \ CC="tuple-gcc --syroot=/path/to/staging" \ CXX="tuple-g++ --sysroot=/path/to/staging" \ LD="tuple-ld --sysroot=/path/to/staging" \ AND_SO_ON=tuple-andsoon --sysroot=/path/to/staging" Or you would need to provide a wrapper to gcc, and still tell configure where to find it... Sigh, that's not easy... Regards, Yann E. MORIN. -- .-----------------.--------------------.------------------.--------------------. | Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: | | +33 662 376 056 | Software Designer | \ / CAMPAIGN | ___ | | +33 223 225 172 `------------.-------: X AGAINST | \e/ There is no | | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL | v conspiracy. | '------------------------------^-------^------------------^--------------------' -- 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] |