Re: Phone call (was Re: Armhf dynamic linker path)

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>
>>And here's the details as promised.
>>
>>I've started a wiki page at
>>
>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>
>>with a strawman agenda for now, and a Doodle poll at
>>
>>http://www.doodle.com/93bitkqeb7auyxn7
>>
>>to see when the best time is for the call on Thursday/Friday. Please
>>fill in the times that work for you ASAP and I'll announce the result
>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>distros and the upstream toolchain developers to be there, able to
>>represent their groups and (importantly) able to make a decision here
>>on what we should do.
>>
>>Apologies for the short notice, but we need a decision quickly.
>
> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
> person who can't make that time is Michael in .nz. Sorry, Michael.

All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
 * is similar to /lib/ld-x86-64.so.2
 * keeps the libraries and loader in the same directory
 * doesn't invent a new /libhf directory
 * is easier to implement in GLIBC
 * is architecture and ABI unique
 * requires less change for distros where the hard float libraries are
already in /lib

I'm happy to do the GLIBC and GCC implementation.

-- Michael

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

2012/4/12 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com>:
> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu:
>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>>
>>>>And here's the details as promised.
>>>>
>>>>I've started a wiki page at
>>>>
>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>
>>>>with a strawman agenda for now, and a Doodle poll at
>>>>
>>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>>
>>>>to see when the best time is for the call on Thursday/Friday. Please
>>>>fill in the times that work for you ASAP and I'll announce the result
>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>>distros and the upstream toolchain developers to be there, able to
>>>>represent their groups and (importantly) able to make a decision here
>>>>on what we should do.
>>>>
>>>>Apologies for the short notice, but we need a decision quickly.
>>>
>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>>> person who can't make that time is Michael in .nz. Sorry, Michael.
>>
>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>  * is similar to /lib/ld-x86-64.so.2
>>  * keeps the libraries and loader in the same directory
>>  * doesn't invent a new /libhf directory
>>  * is easier to implement in GLIBC
>>  * is architecture and ABI unique
>>  * requires less change for distros where the hard float libraries are
>> already in /lib
>
>  Sorry for more bikeshedding, but afaik rpm based distros are
> using the armv7hl identifier, so it could as well be
>
> /lib/ld-linux-armv7hl.so.3

This includes the ABI (h), adds the endianess (l), and implies a
architecture level (v7).  The name for the most common configurations
should be as short as possible so I'd rather drop the 'l' and add a
'b' or 'eb' if anyone wants a big endian distro in the future.  The
architecture level is a problem as the loader should also be valid on
ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
hard float binary that runs on everything, including a potential ARMv6
hard float RaspberryPi build.

>  Other variant could be
>
> /armv7hl-linux/lib/ld.so.3

This introduces both a new directory and a new style for naming :)

-- Michael

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade@gmail.com>:
>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu:
>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
>>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>>>
>>>>>And here's the details as promised.
>>>>>
>>>>>I've started a wiki page at
>>>>>
>>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>>
>>>>>with a strawman agenda for now, and a Doodle poll at
>>>>>
>>>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>>>
>>>>>to see when the best time is for the call on Thursday/Friday. Please
>>>>>fill in the times that work for you ASAP and I'll announce the result
>>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>>>distros and the upstream toolchain developers to be there, able to
>>>>>represent their groups and (importantly) able to make a decision here
>>>>>on what we should do.
>>>>>
>>>>>Apologies for the short notice, but we need a decision quickly.
>>>>
>>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>>>> person who can't make that time is Michael in .nz. Sorry, Michael.
>>>
>>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>>  * is similar to /lib/ld-x86-64.so.2
>>>  * keeps the libraries and loader in the same directory
>>>  * doesn't invent a new /libhf directory
>>>  * is easier to implement in GLIBC
>>>  * is architecture and ABI unique
>>>  * requires less change for distros where the hard float libraries are
>>> already in /lib
>>
>>  Sorry for more bikeshedding, but afaik rpm based distros are
>> using the armv7hl identifier, so it could as well be
>>
>> /lib/ld-linux-armv7hl.so.3
>
> This includes the ABI (h), adds the endianess (l), and implies a
> architecture level (v7).  The name for the most common configurations
> should be as short as possible so I'd rather drop the 'l' and add a
> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
> architecture level is a problem as the loader should also be valid on
> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
> hard float binary that runs on everything, including a potential ARMv6
> hard float RaspberryPi build.

  This means ld.so (and what else? a skype binary should not come fully
statically linked) should be built with -march=armv5te? That is, common
denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
that has a div instruction in thumb mode).

>>  Other variant could be
>>
>> /armv7hl-linux/lib/ld.so.3
>
> This introduces both a new directory and a new style for naming :)

  Well, I said I was sorry for more bikeshedding :-)

> -- Michael

Paulo

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

2012/4/12 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com>:
> Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu:
>> 2012/4/12 Paulo César Pereira de Andrade
>> <paulo.cesar.pereira.de.andrade@gmail.com>:
>>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu:
>>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
>>>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>>>>
>>>>>>And here's the details as promised.
>>>>>>
>>>>>>I've started a wiki page at
>>>>>>
>>>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>>>
>>>>>>with a strawman agenda for now, and a Doodle poll at
>>>>>>
>>>>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>>>>
>>>>>>to see when the best time is for the call on Thursday/Friday. Please
>>>>>>fill in the times that work for you ASAP and I'll announce the result
>>>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>>>>distros and the upstream toolchain developers to be there, able to
>>>>>>represent their groups and (importantly) able to make a decision here
>>>>>>on what we should do.
>>>>>>
>>>>>>Apologies for the short notice, but we need a decision quickly.
>>>>>
>>>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>>>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>>>>> person who can't make that time is Michael in .nz. Sorry, Michael.
>>>>
>>>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>>>  * is similar to /lib/ld-x86-64.so.2
>>>>  * keeps the libraries and loader in the same directory
>>>>  * doesn't invent a new /libhf directory
>>>>  * is easier to implement in GLIBC
>>>>  * is architecture and ABI unique
>>>>  * requires less change for distros where the hard float libraries are
>>>> already in /lib
>>>
>>>  Sorry for more bikeshedding, but afaik rpm based distros are
>>> using the armv7hl identifier, so it could as well be
>>>
>>> /lib/ld-linux-armv7hl.so.3
>>
>> This includes the ABI (h), adds the endianess (l), and implies a
>> architecture level (v7).  The name for the most common configurations
>> should be as short as possible so I'd rather drop the 'l' and add a
>> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
>> architecture level is a problem as the loader should also be valid on
>> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
>> hard float binary that runs on everything, including a potential ARMv6
>> hard float RaspberryPi build.
>
>  This means ld.so (and what else? a skype binary should not come fully
> statically linked) should be built with -march=armv5te? That is, common
> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
>  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
> that has a div instruction in thumb mode).

The architecture and feature set is a different topic and should be
discussed by the distros but I'd rather finish the loader path one
first.  Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have
all taken the opportunity to go to ARMv7 at the same time as switching
to hard float.

-- Michael

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 11 de abril de 2012 22:39, Michael Hope <michael.hope@linaro.org> escreveu:
> 2012/4/12 Paulo César Pereira de Andrade
> <paulo.cesar.pereira.de.andrade@gmail.com>:
>> Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu:
>>> 2012/4/12 Paulo César Pereira de Andrade
>>> <paulo.cesar.pereira.de.andrade@gmail.com>:
>>>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu:
>>>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote:
>>>>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote:
>>>>>>>
>>>>>>>And here's the details as promised.
>>>>>>>
>>>>>>>I've started a wiki page at
>>>>>>>
>>>>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012
>>>>>>>
>>>>>>>with a strawman agenda for now, and a Doodle poll at
>>>>>>>
>>>>>>>http://www.doodle.com/93bitkqeb7auyxn7
>>>>>>>
>>>>>>>to see when the best time is for the call on Thursday/Friday. Please
>>>>>>>fill in the times that work for you ASAP and I'll announce the result
>>>>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant
>>>>>>>distros and the upstream toolchain developers to be there, able to
>>>>>>>represent their groups and (importantly) able to make a decision here
>>>>>>>on what we should do.
>>>>>>>
>>>>>>>Apologies for the short notice, but we need a decision quickly.
>>>>>>
>>>>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST,
>>>>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only
>>>>>> person who can't make that time is Michael in .nz. Sorry, Michael.
>>>>>
>>>>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>>>>>  * is similar to /lib/ld-x86-64.so.2
>>>>>  * keeps the libraries and loader in the same directory
>>>>>  * doesn't invent a new /libhf directory
>>>>>  * is easier to implement in GLIBC
>>>>>  * is architecture and ABI unique
>>>>>  * requires less change for distros where the hard float libraries are
>>>>> already in /lib
>>>>
>>>>  Sorry for more bikeshedding, but afaik rpm based distros are
>>>> using the armv7hl identifier, so it could as well be
>>>>
>>>> /lib/ld-linux-armv7hl.so.3
>>>
>>> This includes the ABI (h), adds the endianess (l), and implies a
>>> architecture level (v7).  The name for the most common configurations
>>> should be as short as possible so I'd rather drop the 'l' and add a
>>> 'b' or 'eb' if anyone wants a big endian distro in the future.  The
>>> architecture level is a problem as the loader should also be valid on
>>> ARMv5 and ARMv6 hard float builds.  Skype should be able to make a
>>> hard float binary that runs on everything, including a potential ARMv6
>>> hard float RaspberryPi build.
>>
>>  This means ld.so (and what else? a skype binary should not come fully
>> statically linked) should be built with -march=armv5te? That is, common
>> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set?
>>  AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r
>> that has a div instruction in thumb mode).
>
> The architecture and feature set is a different topic and should be
> discussed by the distros but I'd rather finish the loader path one
> first.  Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have
> all taken the opportunity to go to ARMv7 at the same time as switching
> to hard float.

  Ok. It obviously should be up to distros if they want the hardfp packages
to be able to run on armv5 with a vfp :-) And so is for skype if they want
it to run on such distro if it exists.  Simpler alternate name would be

/lib/ld-linux-armh.so.3

> -- Michael

Paulo

Re: Phone call (was Re: Armhf dynamic linker path)

[Michael Hope]

On 12 April 2012 12:38, Wookey <wookey@wookware.org> wrote:
> +++ Michael Hope [2012-04-12 12:16 +1200]:
>> 2012/4/12 Paulo César Pereira de Andrade
>> <paulo.cesar.pereira.de.andrade@gmail.com>:
>
>> >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>> >  Sorry for more bikeshedding,
>> > /lib/ld-linux-armv7hl.so.3
>>  I'd rather drop the 'l'
>
> We've already had the GNU triplet-name argument for this ABI. I don't
> think having it again in order to use something slightly different for
> the linker name is very helpful.
>
> Unless of course we find that was another chimera and in fact that's
> not really agreed either...

Sorry, I should have said that in my reply.  I agree, the GNU triplet
should be used.  I couldn't resist going into the past-covered reasons
why.

-- Michael

Re: Phone call (was Re: Armhf dynamic linker path)

[Jakub Jelinek]

On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:

The directory should be /libhf/ or /libhfp/ for that for consistency
with all the other architectures.  Note e.g. x86_64 dynamic linker
is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
For distros that choose to multilib softfp vs. hardfp all the hardfp
libraries would go into the usual */lib{qual} paths (for qual hf resp.
hfp), for others /libhf can be a symlink to /lib or for those doing
multiarch stuff can be a symlink to the multiarch location of the thing.

I'm fine with arm and hf (resp. hfp) being mentioned in the name of
the dynamic linker, but IMNSHO having there gnu and eabi strings
is an overkill - why mention gnu there, when all the other
architectures which also have GNU libc dynamic linkers don't?  That
part is implicit.  And, EABI is implied by so.3, softfp dynamic linker
for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old
ABI is /lib/ld-linux.so.2.

	Jakub

Re: Phone call (was Re: Armhf dynamic linker path)

[Jakub Jelinek]

On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> On 12 April 2012 09:05, Jakub Jelinek <jakub@redhat.com> wrote:
> > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> >
> > The directory should be /libhf/ or /libhfp/ for that for consistency
> > with all the other architectures.  Note e.g. x86_64 dynamic linker
> > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
> 
> For some value of consistency. x86_64, mips64, powerpc64 and sparc64
> install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on

ia64 installs in /lib, because it isn't a multilibbed architecture.

> s390x it is /lib/ld64.so.1 [1].

Ok, I forgot about this, I've tried to convince s390x folks to move it
to /lib64/ld64.so.1 many years ago, but that just didn't happen, so
/lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1.
Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker,
while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.

That is an argument that perhaps /lib/ld-linux-armhf.so.3 could be
acceptable too, as it would follow the s390x model, I wouldn't be terribly
happy about that, but I could live with that.

	Jakub

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1637 bytes --]

On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote:
> > On 12 April 2012 09:05, Jakub Jelinek <jakub@redhat.com> wrote:
> > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > >> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
> > > The directory should be /libhf/ or /libhfp/ for that for consistency
> > > with all the other architectures.  Note e.g. x86_64 dynamic linker
> > > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
> > 
> > For some value of consistency. x86_64, mips64, powerpc64 and sparc64
> > install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on
> 
> ia64 installs in /lib, because it isn't a multilibbed architecture.

because distros choose not to support it.  in first gen chips, there was 
hardware support for running x86.  so if we were to be strict, there should 
have been /libia64/ (or whatever) while the current x86 32bit code would stay 
in /lib/.  but no distro was interested in supporting that (probably due to 
the 32bit x86 layers being balls-ass slow), so it never happened.

> > s390x it is /lib/ld64.so.1 [1].
> 
> Ok, I forgot about this, I've tried to convince s390x folks to move it
> to /lib64/ld64.so.1 many years ago, but that just didn't happen, so
> /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1.
> Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker,
> while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc.

i always thought this was weird.  glad to know i'm not the only one :).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Phone call (was Re: Armhf dynamic linker path)

[Jakub Jelinek]

On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
> > ia64 installs in /lib, because it isn't a multilibbed architecture.
> 
> because distros choose not to support it.  in first gen chips, there was 
> hardware support for running x86.  so if we were to be strict, there should 
> have been /libia64/ (or whatever) while the current x86 32bit code would stay 
> in /lib/.  but no distro was interested in supporting that (probably due to 
> the 32bit x86 layers being balls-ass slow), so it never happened.

We even carried patches (not applied) for lib64 ia64 support in our
binutils/glibc/gcc for a while, but the final decision after these were
written was that it is going to stay in /lib.

	Jakub

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1311 bytes --]

On Thursday 12 April 2012 13:53:13 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote:
> > > ia64 installs in /lib, because it isn't a multilibbed architecture.
> > 
> > because distros choose not to support it.  in first gen chips, there was
> > hardware support for running x86.  so if we were to be strict, there
> > should have been /libia64/ (or whatever) while the current x86 32bit
> > code would stay in /lib/.  but no distro was interested in supporting
> > that (probably due to the 32bit x86 layers being balls-ass slow), so it
> > never happened.
> 
> We even carried patches (not applied) for lib64 ia64 support in our
> binutils/glibc/gcc for a while, but the final decision after these were
> written was that it is going to stay in /lib.

true, it would have been /lib64/ since the hardware doesn't the 64bit 
extensions for x86.  but i think the point still stands that using /lib/ for 
the new hardfloat ABI is OK rather than needing to go the /libhf/ multilib 
route.

and, if it turns out that we were being too optimistic and we do actually want 
soft/hard float multilib, i don't think this will be a blocker.  as mentioned, 
the s390x guys have been bad and it hasn't been a blocker for s390/s390x 
multilib with them :).
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Phone call (was Re: Armhf dynamic linker path)

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1361 bytes --]

On Thursday 12 April 2012 02:05:23 Jakub Jelinek wrote:
> On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
> > All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>
> The directory should be /libhf/ or /libhfp/ for that for consistency
> with all the other architectures.

i think the idea was that no one is looking to do multilib here.  so we won't 
have softfloat in /lib/ and hardfloat in /libhf/.  we're just changing the ldso 
to reflect a change in the ABI.

you could also make this argument for EABI and OABI -- the EABI ldso should 
not be in /lib/.  but since we've got OABI and EABI both in /lib/ and people 
are happy with that, as well as the hardfloat ldso in /lib/, there's no need 
for a sep /libhf/.

> I'm fine with arm and hf (resp. hfp) being mentioned in the name of
> the dynamic linker, but IMNSHO having there gnu and eabi strings
> is an overkill - why mention gnu there, when all the other
> architectures which also have GNU libc dynamic linkers don't?  That
> part is implicit.  And, EABI is implied by so.3, softfp dynamic linker
> for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old
> ABI is /lib/ld-linux.so.2.

i have no opinion either way here.  uClibc has already opted to name things 
with "-uClibc-" in them, so we're clear of collisions there.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: Phone call (was Re: Armhf dynamic linker path)

[Paulo César Pereira de Andrade]

Em 12 de abril de 2012 03:05, Jakub Jelinek <jakub@redhat.com> escreveu:
> On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote:
>> All good.  My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it:
>
> The directory should be /libhf/ or /libhfp/ for that for consistency
> with all the other architectures.  Note e.g. x86_64 dynamic linker
> is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2.
> For distros that choose to multilib softfp vs. hardfp all the hardfp
> libraries would go into the usual */lib{qual} paths (for qual hf resp.
> hfp), for others /libhf can be a symlink to /lib or for those doing
> multiarch stuff can be a symlink to the multiarch location of the thing.

  I would feel a bit better with a commitment for multilib if using /libhf,
but really just to make users life easier. Providing the infrastructure
(by having multilib packages) is asking for it to be used. In the skype
example, if multilib is supported by all distros, skype may as well
provide only an armv5te software float build for linux arm.
  This is the reason, for example, to install skype in my x86_64
computer I need to install 32 bit qt, alsa, X11 libraries, etc to be
able to install x86 skype.

> I'm fine with arm and hf (resp. hfp) being mentioned in the name of
> the dynamic linker, but IMNSHO having there gnu and eabi strings
> is an overkill - why mention gnu there, when all the other
> architectures which also have GNU libc dynamic linkers don't?  That
> part is implicit.  And, EABI is implied by so.3, softfp dynamic linker
> for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old
> ABI is /lib/ld-linux.so.2.
>
>        Jakub

Paulo