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

Re: cortex / arm-hardfloat-linux-gnueabi (was Re: armelfp: new architecture name for an armel variant)

On Fri, Jul 16, 2010 at 09:46:29AM +0200, Loïc Minier wrote:
> On Fri, Jul 16, 2010, Hector Oron wrote:

> > to take it as another architecture, but, nowadays,
> > arm-none-linux-gnueabi supports hard, soft and softfp. Bringing old
> > discussions up to front, would not make sense to have ABI support in
> > the distribution itself (which really is  an overhead) and not in the
> > upstream code?

>  We need a new port because the binaries are incompatible with each
>  others, we need a different triplet because it's a dpkg limitation.

>  Perhaps we could change dpkg to not require that anymore, but we'd
>  still need a new port.  We also need a different triplet for the
>  multiarch use case; I know you're not too interested in multiarch
>  yourself anymore, but it's safer to pick a different triplet
>  nevertheless IMHO, using the vendor field.

I'm puzzled why dpkg needs a unique triplet for a port.  dpkg needs to map
port names to triplets, but why does it need to do the inverse?  And if it
doesn't need to map triplet->port, why would the triplet need to be unique?

There is a need for a distinct port name; I think this is also not a
Debian-specific problem, it's a problem common to any distributions that
want to do what's described here.

Paul commented that:

> Anything that relies on the target triplet is going to break as soon as you
> move outside a pure Debian system. i.e. any patches relying on a particular
> target triplet are inherently Debian specific, and IMO should never be
> pushed upstream.

But, er, relying on the target triplet for this shouldn't be done in Debian,

FWIW, this discussion ties in with one of the known outstanding issues with
multiarch, namely we want to support coinstallation of libraries optimized
for multiple /compatible/ instruction sets.  And we don't want to have to
add /lib/i386-linux-gnu, /lib/i486-linux-gnu, /lib/i586-linux-gnu [,...] to
the path one by one to accomplish that, especially when we already have
hwcaps to do the job for us.  So perhaps triplets aren't the right level of
abstraction to encode in the library paths after all?  I mean, it's ok to
have libraries in /lib/i486-linux-gnu/686/cmov, but we definitely don't want
to *change* the library path if and when Debian's base compatibility level
moves from i486 to i586 (or from armv4t to armv5t, to keep this on topic ;)
and have to deal with path transitions.  Is there a better identifier we
should be using to qualify the library paths, instead of these triplets? 
I.e., instead of the cpu from the triplet, perhaps there are official names
for the ELF architectures that can be used - that can be determined without
too much hard-coding all over the place?

(BTW... if you want to run both armel and armhf under multiarch... which
package's libc gets to own ld.so? :P)

Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek@ubuntu.com                                     vorlon@debian.org

Attachment: signature.asc
Description: Digital signature

Reply to: