On Sunday 26 October 2008 19:12:17 David McCullough wrote: > Jivin Rob Landley lays it down ... > > Does anybody see a reason why the build wrapper should _not_ be added > > back to uClibc, with this change, so people don't have to create a > > separate toolchain just to try out uClibc? > > The uClinux-dist uses a wrapper, ucfront, based loosely on ccache.
My firmware linux project uses a wrapper drived from the one uClibc had years ago. > We use it to build all combinations of stuff like little endian/big-endian, > uClibc/uc-libc and glibc. We use a single multilib'd compiler to build > all combinations. I avoid multilib, it's more complication than I generally want to deal with. > All the toolchains we use in house (which you can download @snapgear.org) > are built against glibc, but they can still build fully functional uClibc > systems without a problem. I am fairly sure the toolchains we use are > configured with the static libgcc.a option to make it easier. That one's not an "easier", that's a "possible" unless you want to build a new libgcc_s.so from source. > As far as I go, the only way you can be sure your dev systems headers and > libs are not polluting your embedded system build is to use a wrapper. The gcc path logic is just horrible, you have to --nostdinc and --nostdlib it to get sane behavior out of the thing. > When we introduced it years ago we found numerous dev host header > dependancies :-( > > I don't have a problem with uClibc using a wrapper, as long as you don't > stop us from being able to use our wrapper ;-) ;-) Nah, this one just be supplying an option. You could still build a native wrapper-less compiler ala buildroot, or use a different wrapper... > Cheers, > Davidm Rob _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
