Gentoo Archives: gentoo-embedded

From: david@×××××××××.com
To: gentoo-embedded@g.o, aja@g.o
Subject: Re: [gentoo-embedded] uClibc/Gentoo/buildroot
Date: Fri, 07 Nov 2003 22:06:47
Message-Id: 20031107220409.GA24590@redhate.futuretel.com
In Reply to: Re: [gentoo-embedded] uClibc/Gentoo/buildroot by AJ Armstrong
On Fri, Nov 07, 2003 at 12:59:25PM -0700, AJ Armstrong wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Although I agree that all ebuilds built for the embedded project should be > part of the portage tree (probably need some new categories), so that they > could be installed using vanilla emerges on platforms with the guts to > support it, should we perhaps consider a new emerge (emberge?, emergemb?, > crossmerge?), using many of the portage facilities, but designed to support > cross-compiling and building a target filesystem, rather than installing on > the local box. This would exist alongside emerge, but have its own config > file structure , etc. >
Well if you go poke around in buildroot you'll notice they have little uclibc patches for openssl and openssh... plus a couple other little tools. I've made my own uclibc toolchain ebuilds, and believe me they aren't easy. Getting gcc to play nice with uclibc is an ugly hack at best... I'm not sure why gcc doesn't have --libc as a autoconf option. anyway, my point was... patches for uclibc compat. It will be interesting to see how much hackage is needed. On the one hand uclibc people see to suggest that everything should 'just work'(tm), but they provide an awful lot of patches that suggest the contrary. so making a different tree may be the answer, but keeping it 'in sync' with gentoo-portage doesn't sound like fun.
> such supstantial changes in portage and things like make.conf that we're > unlikely to get them without (1) a long fight (2) giving up some things we > want. Also, multi-platform cross-compiler support is such a significant > retrofit that I'm wondering if it wouldn't result in either a nasty > bag-on-the-side or a second system effect if we try to re-engineer portage. >
maybe we have to put in our suggestions to portage 2.0 redesign and hope :-( and as for namings ... I'm partial to submerge ;-) but I felt I was clever in naming that. Dave -- gentoo-embedded@g.o mailing list