Re: Support for uclibc (and other such variations on an arch)
Hi Ron,
On Sat, 2007-05-19 at 00:26:22 +0930, Ron wrote:
> The uclibc library is a valuable option for small embedded systems with
> relatively simple needs, but trying to integrate it into a Debian system
> crosses some lines at a granularity that we have not previously recognised.
For sure.
> I'm aware of two existing approaches to answering the first question:
> One is that taken by the SLIND project, which is to use the existing
> divisions and declare uclibc based builds to be an entirely new Debian
> architecture. This adds no extra complexity to the existing build tools
> and has been proven by them to work. On the downside, it means geometric
> growth for the list in /usr/share/dpkg/archtable, and that we need to
> find some way to support adding additional arch types there which may
> not actually be in the list of arch's officially available from normal
> debian.org mirrors.
I'm not entirely aware of the whole picture on SLIND, but I certainly
agree on using a new arch. Also archtable, as stated in the same file,
is mostly of historical relevance, and thus only contains official
arches on the Debian mirrors. To add uclibc support, only a line on
ostable and triplettable would be needed. I've been close to add those
in the 1.14.x branch but didn't, to avoid unilaterally deciding on the
arch name. But that would something like:
,--- ostable ---
uclibc-linux linux-uclibc linux[^-]*-uclibc
`---
,--- triplettable ---
uclibc-linux-<cpu> uclibc-linux-<cpu>
`---
So the architecture name would end up being: uclibc-linux-arm.
> The alternative proposal is, that since uclibc and glibc can ostensibly
> be installed together on a system, both really fall under the same arch
> type, and all that is really required is to discriminate them using the
> gnu type triplet, ie. *-linux-gnu and *-linux-uclibc, both for arch *.
> This does not require modification of the dpkg archtable, but it will
> require tools such as dpkg-cross (and dpkg-architecture to a lesser
> extent) to be modified to accept an explicit triplet specification in
> place of the current practice of inferring it from the Debian arch.
This would be wrong, for several reasons. Currently the Debian arch to
GNU triplet is a one to one mapping. And do not mix the fact that they
can be installed in parallel with the fact that they must not be linked
on the same binaries, that makes them different arches [0].
> It also seems a little more extensible, since low level alternatives
> for things other than libc (and alternatives other than uclibc) won't
> also have to ask the question of 'does this make it a new arch or not?'
> (Do we really want to give the dpkg maintainer a lesson in geometry
> like that could turn out to be? ;-)
If those low level parts have been built with a specific gnu-triplet
toolchain they should be bound to the matching Debian architecture, as
other parameters like alignment, etc can change with the toolchain
target.
> It seems unlikely and even undesirable that anyone would ever want to
> actually use both C libraries on the same target system, but what we
> do want is to cleanly support both in cross building environments.
With multiarch[1], both using and building (or cross-building) with
different architectures coninstalled, should just work, in case someone
sees the need.
regards,
guillem
[0] We do transitions all the time from abi breaking libraries with
different sonames, we have even done an executable file format
switch (a.out -> elf) gracefully in the past. That does not mean
coinstallability (or some kinds of it) is the right answer all the
time (take the armel case as example).
[1] Which is for now mostly blocked on binutils.
Reply to: