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, either! 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/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
