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
1 On Fri, Nov 07, 2003 at 12:59:25PM -0700, AJ Armstrong wrote:
2 > -----BEGIN PGP SIGNED MESSAGE-----
3 > Hash: SHA1
4 >
5 > Although I agree that all ebuilds built for the embedded project should be
6 > part of the portage tree (probably need some new categories), so that they
7 > could be installed using vanilla emerges on platforms with the guts to
8 > support it, should we perhaps consider a new emerge (emberge?, emergemb?,
9 > crossmerge?), using many of the portage facilities, but designed to support
10 > cross-compiling and building a target filesystem, rather than installing on
11 > the local box. This would exist alongside emerge, but have its own config
12 > file structure , etc.
13 >
14
15 Well if you go poke around in buildroot you'll notice they have little
16 uclibc patches for openssl and openssh... plus a couple other little
17 tools.
18 I've made my own uclibc toolchain ebuilds, and believe me they aren't
19 easy. Getting gcc to play nice with uclibc is an ugly hack at
20 best... I'm not sure why gcc doesn't have --libc as a autoconf option.
21
22 anyway, my point was... patches for uclibc compat. It will be
23 interesting to see how much hackage is needed. On the one hand uclibc
24 people see to suggest that everything should 'just work'(tm), but they
25 provide an awful lot of patches that suggest the contrary.
26 so making a different tree may be the answer, but keeping it 'in sync'
27 with gentoo-portage doesn't sound like fun.
28
29 > such supstantial changes in portage and things like make.conf that we're
30 > unlikely to get them without (1) a long fight (2) giving up some things we
31 > want. Also, multi-platform cross-compiler support is such a significant
32 > retrofit that I'm wondering if it wouldn't result in either a nasty
33 > bag-on-the-side or a second system effect if we try to re-engineer portage.
34 >
35
36 maybe we have to put in our suggestions to portage 2.0 redesign and
37 hope :-(
38
39 and as for namings ... I'm partial to submerge ;-) but I felt I was
40 clever in naming that.
41 Dave
42
43 --
44 gentoo-embedded@g.o mailing list