Hi Paul, I understand your concerns, but the biggest problem with a toolchain is that some configure and Makefiles in sources have hardcoded paths in it to system libraries (or use libtool). Even with a toolchain it is possible that sources can't be compiled or are "polluted" with "leaking" libraries (or include files) from the host system.
The only solution is to create a chrooted or standalone build environment where the uClibc libraries are native so problems with leaking libraries won't happen. It has nothing todo with testing packages, only with building and compiling. We like to keep this option open, but I agree we must be very carefull to remove the builded binaries and libraries in the staging directory (with a clean). The build environment should be clean, gcc and the loader won't include libraries or include files from the host system. But most problems with cross pollution are due to individual sources with hardcoded paths in configure ore Makefile. I'm not sure how good the buildenv is while running under freebsd or powerpc to crosscompile, but I'm sure you will hit a lot of problems :-) Eric ---------------------------------------------------------------------- Sigh, I forgot, I already asked this question in Feburary, I just didn't like the answer then so I forgot it... K.-P. Kirchd�rfer wrote: > The long term idea by Arne or Martin has been to chroot into staging > and run our own distro from there. > I've asked myself, but then with all the problems with some packages > leaking on some machines, I understood it may help in the long run. I happen to disagree on this one, but I'll follow their lead... I think that it's more important to keep staging dir clean, and if you want to test-run a distro (assuming you have the same CPU), you could/should just have a small script that untar's all the LRPs into a chroot jail. That way you also test to make sure the .lrp's were packaged correctly (you remembered to include all the files the router needs). I feel that the staging directory really should be reserved for the toolchain and supporting libraries (i.e. include files and shared libraries) required by other packages. I've been building both debugging and non-debugging versions of upnpd, and I live in fear that I didn't sanitize staging_dir and clean out the old libraries. It's much easier to just rm -rf target_dir/upnpd and not worry. It also means I can have separate versions of upnpd in the tree and not have them install crap over each other. Minor point, but just wanted to share my two cents. I'll follow the current consensus of the group. Paul p.s. has anyone tested how "clean" our build environment really is? I've got some worries about include file and library file cross-polination from the host build environment...but I haven't dug into the gcc spec file for the cross compiler to make sure it never includes anything from /usr/include and LD never looks at /usr/lib. can buildtool run under freebsd to produce a LEAF binary? can buildtool run on a powerpc to produce an i386 binary? ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ leaf-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/leaf-devel
