On Sunday 19 October 2008 04:48:21 Vladimir Dronnikov wrote: > >>> > supply a cross compiler for the host system? > >> > >> It's pretty trivial... > > Pity that noone ships a tarball of x86 toolchain which could be just > untarred to the rootfs and has out-of-box means to build, say, > buildroot for x86. Cross compiling is indeed very important task but > native tools are of not less importance, imo.
A) A native build would mean having a completely uClibc root filesystem. Compiling uClibc under glibc is still cross compiling. A native build is what I'm _trying_ to provide. B) I do have cross compiler tarballs. Last I checked, buildroot wants to build its own toolchains, and thus discards ones you provide on the host. C) Buildroot doesn't have releases. I'd be happy to try to debug a _specific_ release of buildroot, but they've categorically refused to ever do this. (I've argued about it before.) > Still AFAICS buildroot doesn't accept external toolchains cleanly: it > is supposed that one should build uClibc/gcc/binutils from scratch, > but I want to use, say, precompiled Rob's tool and libes. Still > uclibc/busybox based tools do not fit buildroot (which is claimed to > support them, right?). There's two issues here: 1) Getting buildroot to use externally supplied prebuilt cross compilers is non-obvious. 2) Trying to build builldroot under a busybox-based development environment may hit some hiccups in busybox. I'm trying to squash these bugs where I find them. (I know of one in binutils on arm, which I'm tracking down.) > Still bison and flex (and evil gettext) > binaries are must-pre-have on the host system. They can be built. For example, I'm working on a script to bootstrap Linux >From Scratch 6.3, using FWL as the LFS as the "temporary system" (I.E. chapter 5). Unfortunately, the version of glibc they've got categorically refuses to build on a host that doesn't have Thread Local Storage. I could just skip that and do a uClibc based LFS (or a uClibc+busybox based one and skip most of the gnu tools), but I want to make sure it's capable of building a vanilla LFS for the target, and that means glibc. Hence me wandering back here and agitating for a 0.9.30 release to act as a base to put TLS on. (I don't care about the NPTL branch, it's been vaporware for years now.) > Still an unavoidable > assumption of host system has the support for shared libes sustains. Um, the host system does support shared libraries. /tools/lib is shared libraries. I'm confused? > My, I don't know whether to spend man-hours to patch buildroot for my > needs or get back to my old building system. I'd strongly prefer the > former but am not so fluent in the guts of buildroot... :( I've been poking at buildroot on and off for a long time. (I'm the one who created the buildroot mailing list, to move that traffic off _this_ list.) I've never had much luck actually using buildroot because I have some fundamental design problems with it: A) It's a series of nested makefiles, so trying to figure out what happens in which order is nontrivial. B) It doesn't have releases, ever. You just grab a random snapshot out of source control and hope today's isn't broken. That's their official policy. C) Creating a cross compiler and building a target system aren't cleanly separated. If I already have a cross compiler and want it to use it, or just want it to produce a cross compiler for use elsewhere, or if I want to build entirely natively, it's really not set up for that. It's an integrated, non-orthogonal whole. (You can sometimes pick it apart if you really know what you're doing, but you shouldn't _have_ to.) Rob _______________________________________________ uClibc mailing list [email protected] http://busybox.net/cgi-bin/mailman/listinfo/uclibc
