[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Support for uclibc (and other such variations on an arch)



Hi,

It would appear a number of people have been thinking about this issue
for a while now, so I'd like to inject a little energy into the process
(read: I'm volunteering to do the work ;), to arrive at a consensus and
implementation that we think will be workable for Lenny and beyond.

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.

When you boil it right down, the key questions here really are:

 - Where are those lines?
 - And what are we going to name them?

If we can all agree on the answer to those two, everything else should
be Easy(tm).

What follows is a summary of discussion over the last few days on #emdebian
and my limited knowledge of what we know and what has been tried.  I do
think that we have enough people with enough experience now to try and
polish this into some more concrete guidelines for best practice, and
make positive identification of which tools need to be modified and how.

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.

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.

For example: `dpkg-architecture -aarm -tarm-linux-uclibc` complains,
but does more or less the right thing here.  dpkg-cross would need
similar support which it does not yet have.  Some packages such as
gcc would need their /rules updated to accept both a Debian arch or
a triplet as binutils currently does.  Neither of those things seems
terribly difficult to do, but there may be other as yet unseen issues
with this approach.  An example of this approach with the uclibc
library itself in a form that could be uploaded to Sid today can be
found at: http://people.debian.org/~sjr/

It does lend itself well to the autoconf idom for cross compiling,
where any source package (debianised or not) can make its selection
of target host and lib with something like:
$ ./configure --build=$(./config.guess) --host=arm-linux-uclibc
But with proper dpkg-cross support, packages from a separate arch
should be able to do the same just as easily.  It should be just
as easy to locally install libs that aren't yet debianised if we
get this right.

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? ;-)

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.

It is unclear (to me at least), which of these two solutions really
does support the latter in the simplest and most easily extensible
way, SLIND has a clear lead in that it is actually working today,
but I'll let others elaborate on what they consider the primary
pros and cons of each approach -- I think there is a middle ground
here that does hold the best of both worlds and which belongs in
Debian as our definition of Universal grows to encompass, well,
everything.

So...

Keeping to the theme of binary slicing until this becomes simple enough
to deal with, I think there are two distinct phases for what we need
to do to have a working and workable solution:

 - go point by point through the merits of the above two approaches
   (and any other promising contenders) in the hope that a clear
   winner will emerge.  This includes any polishing to either that
   might be revealed along the way.

 - When we have consensus on what really does meet everyone here's needs,
   engage the package maintainers of any affected packages with a clear
   policy proposal, followed by patches to implement it.

Eat, Sleep, Be Merry, Repeat if we hit a veto from someone over something
we forgot...

Ok, so that's more than enough from me to get the discussion started,
the people best equipped to add wise comments here already understand
most of the issues better than I do anyway, so if we can get all your
ideas together to see which bits break each others logic in ways that
we can fix then we should have a Debian grade answer before too long.

what follows from here then are the raw logs of the salient bits from
the last few days of #emdebian.  Feel free to chop this into as many
separate subthreads as we need to keep the various worms that crawl
out of this can clearly in focus.  This is already too long to read,
so including all of it in a reply might not be ideal -- the general
ideas seem well known enough, its the specifics that we need to pin
down and prove now more than anything else.  That is too big for any
of us to figure out alone, but between us I think we'll do alright.

If you did get this far, Thanks!  I hope to make it worth your while.

 Ron


<ron> what problems remain with getting uclibc support in native dpkg?
      I thought I saw a message on the emdebian list a while back with
      a solution to resolve that.
<ron> is there anything I can do to help make that happen?

<GyrosGeier> ron, uclibc can be installed in parallel with glibc
<GyrosGeier> ron, as such rebuilding the packages against uclibc without
	     changing anything else should be fine
<GyrosGeier> for that, (in theory) it should be enough to set
	     DEB_HOST_GNU_TYPE without changing DEB_HOST_TYPE, but
             dpkg-architecture will probably not like that

<ron> GyrosGeier: hmmm...  it looks like the slind stuff is currently
      switching off DEB_HOST_ARCH*, but with what you say in mind, I do
      wonder why it should not act on DEB_HOST_GNU* instead ...
<ron> dpkg-architecture moans about dpkg-architecture -aarm -tarm-linux-uclibc
      not matching defaults it expects, but it does seem to do the right thing
<ron> virtuoso: historical reasons aside, can you see any reason this should
      not work now?

<GyrosGeier> I guess I should finally upload the uclibc stuff

* GyrosGeier/#emdebian goes back to sleep

<ron> GyrosGeier: looks like the crux of what we talked about last night
      falls on dpkg-cross and the gcc packaging
<ron> if we can teach both of them to accept a GNU triplet directly instead
      of inferring one from a debian arch, then I think it will go a long way
      toward working...
<ron> anyone know why that might not fly?

<wart> ron: Because there's actually a correspondence between debian arch and
       gnu arch triplet?

<GyrosGeier> which is a slight problem when building for uclibc

<ron> It seems we can probably just use arch = arm, and gnu = arm-linux-uclibc
<ron> but deriving the latter from the former gives us arm-linux-gnu instead

<wart> No, you just can't do that. There is a fixed table in dpkg.

<ron> it seems what we need is a way to override just the triplet, not the
      debian arch, no?

<wart> arm is arm-linux-gnu which is glibc.
<Baby> yup, slint had to patch it to be able to use uclibc-i386 and such
<wart> That's it.

<ron> I am able to build binutils like that, only dpkg-cross and gcc seem to
      be trouble
<ron> dpkg-architecture -aarm -tarm-linux-uclibc

<Baby> i ported those patches to the latest dpkg some weeks ago, when i was
       trying some things
<Baby> but yep, you need that patched dpkg stuff or it won't let u do anything

<ron> wart: but arm-linux-uclibc can be installed in a arm-linux-gnu target
<ron> so to debian they could both just be -aarm?

<Baby> so then the difference should be in the package name?

<ron> that's more or less what I'm seeing so far...
<ron> I've patched toolchain-packge to use this, and it builds binutils ok
      with native dpkg and tools
<ron> the trouble starts because dpkg-cross doesn't know how to take a triplet
      like dpkg-architecture does
<ron> and because gcc /rules take a debian arch only, unlike binutils with
      will also take an explicit triplet
<ron> neither of those seem terribly hard to fix...

<GyrosGeier> that's the idea

<ron> I'd really like to build consensus on how we should tackle this, I'm
      happy to do the work, but I'm the newbie here so I'm still coming up
      to speed on everyone else's expectations and what sort of patches might
      be accepted...
<ron> GyrosGeier: do you think I'd get a -t like option into dpkg-cross ok?

<ron> wart: does it strike you that there is something wrong with this package
      name: libuclibc-dev-uclibc-arm-cross_0.9.28svn20060414-1slind0_all.deb
<ron> one too many uclibc's in there perhaps?  That would go away if
      arm-linux-uclibc were just a subtype of the debian arm arch

<wookey> ron: it does seem to me that having a whole extra arch just to change
         the c-library is not the nicest solution
<wookey> I am sure dpkg-cross will accept a patch to take the triplet if we
         think it will work
<wookey> And I'd hope we can persuade the gcc people too

<ron> gcc should be easy, we just need to make it do something like binutils
      does, where $TARGET can be a debian arch or a triplet, the code to do
      that seems trivial enough

<wookey> but like wart says, currently there is a strong expectation that arch
         specifies c-library. However now that we can install both at once that
	 expectation has been shown to be wrong 
<wookey> ron: indeed

<ron> dpkg-cross has a few more possibilities...  the simplest is to add a -t
      option like dpkg-architecture has
<ron> I'm not sure if we can have it instead of -a or if we'll need both...
<ron> can we reliably infer -aarm from -tarm-*-*?

<wookey> and whilst we are at it we could fix the fact that it doesn't build
         when (HOST=TARGET) !=BUILD 

<wart> ron: I once thought that it would be possible -- to have uclibc only
       as a virtual architecture on dpkg-cross level. But then it turned out
       to be quite a nasty idea.

<wookey> it needs some thought to make sure that dpkg-cross will know what it
         should do

<ron> Is there a better place than here to have that discussion?
<wookey> I think that doing it on a mailing list has some advatanges - it is
         important and complex - archiving the discussion is good

<ron> wart: where did it get nasty?  do you recall?

<wart> I don't really grok why is that needed.
<wart> At all.

<ron> wart: sorry, why $what is needed?

<wookey> it is much easier to get patches to dpkg-cross, uclibc and gcc into
         debian than a whole new arch

<wart> Having uclibc builds as glibc architectures.
<wart> Come on, dpkg already includes waay lot of really strange architectures.
<wart> Even win32, iirc.

<ron> it wouldn't be 'as a glibc arch', it {c,w}ould just install in parallel
      with one

<wookey> I suppose so long as we are not actually building said arch in debian
         then you are right (wart)
<wookey> but arches should be incompatible, shouldn't that?

<ron> Personally I don't really mind either way, but I would like to get the
      answer in mainline dpkg etc.

<wookey> I think to get it in mainline it needs to be named opposite-way round
         to slind arm-uclibc, not uclibc-arm, to fit with rest of systemk
	 nomenclature 

<ron> wart: mingw doesn't depend on dpkg support, its a bit different to this

<wookey> well wart has shown that a new arch works
<wookey> so you could just try it the triplet way and that way we get to find
         out what breaks?

<ron> If no-one can think of fundamental reasons not to do that, I'll make a
      prelim patch to dpkg-cross like I've done for toolchain-package and we'll
      see how far that goes

<wookey> it comes down to a question of what _is_ debian arch. does it == one
         gnu triplet, and we shouldn't break that?
<wookey> or does it cover a set of compatible stuff that will run on one box?
<wookey> (together)

<wart> ron: Why would you want to have both uclibc and glibc packages on the
       same host?

<GyrosGeier> probably both
<GyrosGeier> the "will run together" definition is what we can write into policy
<GyrosGeier> wart, transition
<GyrosGeier> I'm not sure on the definition for the fourth field of the triplet
<GyrosGeier> right now we use it to denote "variant"

<wart> GyrosGeier: transition?

<ron> wart: that's not really what I'm aiming for, though if they can co-exist
      without conflict it would seem to be the slightly simpler of the two
      choices

<GyrosGeier> but that can be compatible, like "uclibc", or incompatible, like
             "eabi"

<wart> ron: So what's you main target then?

<GyrosGeier> ron, also that

<ron> what I really want is to be able to use uclibc, so the big question right
      now is where to put it...

<GyrosGeier> ron, it certainly made the uclibc packages a lot easier

<ron> GyrosGeier: That's what I found with mingw, and the wx-cross packages,
      that can not only have different arches' but also a million or so
      different combinations of its own build config...
<ron> all mutually incompatible, but all able to be installed side by side
<ron> and selected with a build flag rather than a schroot
<ron> wart: The slind uclibc tools are very close to what I'm after...
      mainly I'd just like to see that work with pristine dpkg tools

<GyrosGeier> http://people.debian.org/~sjr/ has uclibc source packages that
	     are more or less what I'm going to upload
<GyrosGeier> hmm wait

<wart> I would just approach Guillem and ask him to patch dpkg.
<wart> That's it.

<wookey> GyrosGeier: is your scheme for parallel uclibc install actually
	 incompatible with doing it the slind way?
<wookey> i.e. do we have to choose?

<GyrosGeier> I haven't looked at the slind way

<ron> wart: to add uclibc-arm?  Has anyone already asked?

<wart> ron: I think there were no major objections.

<GyrosGeier> I install libs into /lib, with different names so no conflict
<GyrosGeier> and devel files go into /usr/<cpu>-linux-uclibc/(include|lib)

<wookey> ron: it has been discussed on the debian-embedded list a couple of times
<wookey> I don't think guillem has spoken one way or the other

<ron> yeah, I actually thought it had been resolved from a messages I saw a
      while back...
<ron> but that must have been something else

<wookey> we should certainly ask what he thinks. There was some debate about
	 naming and 'what about all the other options'

<GyrosGeier> biggest problem is that I have a cold, so I don't have access to
	     all of my sources, since they are at work
<GyrosGeier> so the stuff on people.d.o is outdated by a few days, but I don't
	     remember doing any changes after that
<GyrosGeier> anyway, I'm going to take a nap now

<wart> virtuoso says he's seriously against everything :))

<GyrosGeier> another thought I had
<GyrosGeier> uclibc alone is pretty pointless
<GyrosGeier> we also want other libraries linked against uclibc
<GyrosGeier> my uclibc-toolchain package makes gcc prefer the uclibc lib dir
	     when called through the uclibc wrapper
<GyrosGeier> but libraries depending on a particular libc will either have to
	     have their soname adapted or they cannot be installed at the same
	     time as the glibc variants
<GyrosGeier> in an ideal world, it doesn't matter what libc a library I'm using
	     depends on
<GyrosGeier> but there may be problems with different ld.so and stupid libraries
	     reexporting libc ABI

<p2-mate> and uclibc lacking some bits like tz file parsing

<GyrosGeier> that shouldn't be an ABI incompatibility
<GyrosGeier> hmm

<p2-mate> euh ? it is

<ron> yeah, if you use uclibc you know what things you are giving up...  if you
      need glibc functions, there is little point having both, just use glibc.so
      for everything, that is smaller than both

<GyrosGeier> multiple malloc implementations is a far bigger problem
<GyrosGeier> p2-mate, as in, stuff won't break if you have both in the same
	     executable image

<ron> I don't see much value in have both on a target, its really only for cross
      building where you might want that

<GyrosGeier> indeed

<ron> any particular target should be one or the other...
<ron> which I guess is another tick for the make it *-arm or arm-* as a real
     (sub)arch method

<p2-mate> GyrosGeier: it can break 

<GyrosGeier> but the requirements for "can be installed together on the host"
	     are stricter than "can be installed together on the target"

<p2-mate> using both in the same executable is not going to work anyway
<p2-mate> but installing both still makes sense for testing

...

<wookey> did anyone log all that? It contained some imprtant info.
	 ron - do you want to try and turn this discussion into an email?




Reply to: