Re: Armhf dynamic linker path

2012-04-09 Thread Adam Conrad
On Wed, Apr 04, 2012 at 11:11:30PM -0400, Mike Frysinger wrote:
> On Wednesday 04 April 2012 22:48:34 Wookey wrote:
> > Mike Frysinger [2012-04-02 19:56 -0400]:
> 
> trying to paint the use of a triplet in the path as any other than multiarch 
> is bunk.  as Joseph explained in detail, there already is a standard in 
> mainline tools.  if you want to change the standard, then propose something 
> consistently for everyone.  backdooring it for 1 target is not the way.

It's not readily changable for all targets, and you know that (or, at least,
I hope you know that?).  As Jeff Law said at Plumbers (where there were Gentoo
people sitting in as well, whose opinion was "Gentoo doesn't care, do whatever),
"This is something we should have been doing for the last twenty years".

I appreciate that it's irksome to have to deal with Debian's terrible and
unreasonable desire to install more than one base architecture at the same
time, but while you accuse us of "backdooring" (we intentionally brough people
together to discuss this, repeatedly), are you not just as much hindering
Debian over nothing more than a path to a single file?

To be very, very, very clea here.  multilib can not solve the "different base
arches on one system problem".  lib/lib32/lib64/libhf/libsf will overlap as
soon as you have more than one of x86, arm, power, mips, etc.

To be extra clear, we're NOT asking people to implement multiarch.  We'd like
that to happen some day, but this isn't some "slippery slope", this is the
path to ONE file.  One.  In Debian, we currently have that path (for, say,
x86_64) in locations we'd no prefer.  We don't argue with the world that it's
ugly, we just place the linker where everyone else does.

In the armhf case, given that very few of us were shipping armhf, and only
some of us had really bootstrapped an archive worth talking about, we felt
that we could discuss this last year and reach a consensus.  And we did.  At
least, we did until it got bikeshedded to death more than six months later.

I'll agree with you that Debian's multiarch doesn't account for every possible
ABI, as it only accounts for (oddly enough), the ones that they ship.  This
could be fixed.

I'll also agree that having the linker in an ABI-unqiue (including arch-unique,
which multilib CAN NOT provide) path would be ideal, though we all know that
i386 and x86_64 will probably end up carrying compat symlinks for years to
deal with all the commercial software.  Thankfully, most non-x86 ports could
actually just hard-switch and carry on with it.

Again (and again, and again), this isn't about Debian trying to push multi-
arch on people, it's about having a linker path that works for everyone.  The
proposed /lib/(arbitrary-unique-name)/ld-linux make it work for everyone, but
some say it's "ugly" or "unsightly", or downright backdoorish.  The proposed
"keep with the status quo and use multilib paths" works for some people, but
not others.  If that's the route we have to take, we'll take it, and live with
the happy accident that /libhf/ld-linux.so.3 happens to not overlap with any
arch most people care about right now, but that happy accident doesn't make
it the sane ongoing solution.  I'm sure people can take a step back and see
that without it being some "us versus them" argument.

... Adam

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain


2012.04 release prep

2012-04-09 Thread Michael Hope
Hi there.  The 2012.04 toolchain release is this week.

Ulrich, I see your fix for LP: #968766 has been approved upstream.  In
theory it's too late but I'm happy to land it if you are.  Could you
decide and let Andrew know by the middle of Tuesday?  Andrew, if you
don't hear from Ulrich then spin away.

Andrew, could you run the release process on Tuesday please?  There's
one extra step this month: once you've uploaded and spawned the job,
go to the scheduler screen and click on 'Release' beside each of the
ursas.  I reserved them to make sure they'd be idle and ready to pick
up the release build when ready.

Thiago, let us know if Ulrich or I can lend a hand with the GDB release.

-- Michael

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain


Re: Armhf dynamic linker path

2012-04-09 Thread Mike Frysinger
On Monday 09 April 2012 15:47:56 Adam Conrad wrote:
> are you not just as much hindering Debian over nothing more than a path to a
> single file?

nope.  sounds more like self inflicted pain.

> To be very, very, very clea here.  multilib can not solve the "different
> base arches on one system problem".  lib/lib32/lib64/libhf/libsf will
> overlap as soon as you have more than one of x86, arm, power, mips, etc.

no one is saying it can (or at least, i'm certainly not).  my point is that 
many people don't see this as a "problem".
-mike


signature.asc
Description: This is a digitally signed message part.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain


Re: Armhf dynamic linker path

2012-04-09 Thread Jeff Law

On 04/09/2012 10:19 PM, Mike Frysinger wrote:

On Monday 09 April 2012 15:47:56 Adam Conrad wrote:

are you not just as much hindering Debian over nothing more than a path to a
single file?


nope.  sounds more like self inflicted pain.


To be very, very, very clea here.  multilib can not solve the "different
base arches on one system problem".  lib/lib32/lib64/libhf/libsf will
overlap as soon as you have more than one of x86, arm, power, mips, etc.


no one is saying it can (or at least, i'm certainly not).  my point is that
many people don't see this as a "problem".
Don't the multilib paths contain enough information to handle this? 
They certainly have in the past as I can recall building toolchains that 
handled several architectures within power, arm & mips families in the past


Is the problem here that glibc simply isn't building multilib paths in 
the same way that GCC has for the last 15 years?


jeff

___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain


Re: Armhf dynamic linker path

2012-04-09 Thread Mike Frysinger
On Tuesday 10 April 2012 00:23:09 Jeff Law wrote:
> On 04/09/2012 10:19 PM, Mike Frysinger wrote:
> > On Monday 09 April 2012 15:47:56 Adam Conrad wrote:
> >> To be very, very, very clea here.  multilib can not solve the "different
> >> base arches on one system problem".  lib/lib32/lib64/libhf/libsf will
> >> overlap as soon as you have more than one of x86, arm, power, mips, etc.
> > 
> > no one is saying it can (or at least, i'm certainly not).  my point is
> > that many people don't see this as a "problem".
> 
> Don't the multilib paths contain enough information to handle this?
> They certainly have in the past as I can recall building toolchains that
> handled several architectures within power, arm & mips families in the past

his point is you can't install multiple architectures into the same root.  
alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2.  a 
quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other 
collisions.

> Is the problem here that glibc simply isn't building multilib paths in
> the same way that GCC has for the last 15 years?

afaik, glibc and gcc should be in sync ... can't say i've noticed issues with 
all the arches Gentoo supports.
-mike


signature.asc
Description: This is a digitally signed message part.
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain