[PATCH] ARM: Use different linker path for hardfloat ABI

[PATCH] ARM: Use different linker path for hardfloat ABI

[dann frazier]

This is an updated version of a patch Debian and Ubuntu are using to
use an alternate linker path for hardfloat binaries. The difference
with this one is that it covers the case where no float flag
was passed in, defaulting to the softfloat path.

2012-03-29  dann frazier <dann.frazier@canonical.com>

	* config/arm/linux-elf.h: Use alternate linker path
          for hardfloat ABI

Index: gcc/config/arm/linux-elf.h
===================================================================
--- gcc/config/arm/linux-elf.h	(revision 185708)
+++ gcc/config/arm/linux-elf.h	(working copy)
@@ -59,14 +59,21 @@
 
 #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
 
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
+#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
 
 #define LINUX_TARGET_LINK_SPEC  "%{h*} \
    %{static:-Bstatic} \
    %{shared:-shared} \
    %{symbolic:-Bsymbolic} \
    %{rdynamic:-export-dynamic} \
-   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
+   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
+   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
+   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+   %{!mfloat-abi: \
+     %{!msoft-float: \
+       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
    -X \
    %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
    SUBTARGET_EXTRA_LINK_SPEC

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 29/03/12 20:34, dann frazier wrote:
> This is an updated version of a patch Debian and Ubuntu are using to
> use an alternate linker path for hardfloat binaries. The difference
> with this one is that it covers the case where no float flag
> was passed in, defaulting to the softfloat path.
> 
> 2012-03-29  dann frazier <dann.frazier@canonical.com>
> 
> 	* config/arm/linux-elf.h: Use alternate linker path
>           for hardfloat ABI
> 
> Index: gcc/config/arm/linux-elf.h
> ===================================================================
> --- gcc/config/arm/linux-elf.h	(revision 185708)
> +++ gcc/config/arm/linux-elf.h	(working copy)
> @@ -59,14 +59,21 @@
>  
>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>  
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>  
>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>     %{static:-Bstatic} \
>     %{shared:-shared} \
>     %{symbolic:-Bsymbolic} \
>     %{rdynamic:-export-dynamic} \
> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{!mfloat-abi: \
> +     %{!msoft-float: \
> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>     -X \
>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>     SUBTARGET_EXTRA_LINK_SPEC
> 

Looks to me as though this will break the old Linux ABI.  While we've
marked that as deprecated, it hasn't been removed as yet.  So I think
this patch either needs to wait until that removal has taken place, or
provide the relevant updates to maintain the old ABI support.

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[dann frazier]

On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> On 29/03/12 20:34, dann frazier wrote:
> > This is an updated version of a patch Debian and Ubuntu are using to
> > use an alternate linker path for hardfloat binaries. The difference
> > with this one is that it covers the case where no float flag
> > was passed in, defaulting to the softfloat path.
> > 
> > 2012-03-29  dann frazier <dann.frazier@canonical.com>
> > 
> > 	* config/arm/linux-elf.h: Use alternate linker path
> >           for hardfloat ABI
> > 
> > Index: gcc/config/arm/linux-elf.h
> > ===================================================================
> > --- gcc/config/arm/linux-elf.h	(revision 185708)
> > +++ gcc/config/arm/linux-elf.h	(working copy)
> > @@ -59,14 +59,21 @@
> >  
> >  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
> >  
> > -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> > +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
> > +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
> >  
> >  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
> >     %{static:-Bstatic} \
> >     %{shared:-shared} \
> >     %{symbolic:-Bsymbolic} \
> >     %{rdynamic:-export-dynamic} \
> > -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> > +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> > +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
> > +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> > +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> > +   %{!mfloat-abi: \
> > +     %{!msoft-float: \
> > +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
> >     -X \
> >     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
> >     SUBTARGET_EXTRA_LINK_SPEC
> > 
> 
> Looks to me as though this will break the old Linux ABI.  While we've
> marked that as deprecated, it hasn't been removed as yet.  So I think
> this patch either needs to wait until that removal has taken place, or
> provide the relevant updates to maintain the old ABI support.

Thanks for your review. You're right, this does appear to break the
old ABI - that was a misunderstanding on my part. I think this fixes
the problem:

Index: gcc/config/arm/linux-elf.h
===================================================================
--- gcc/config/arm/linux-elf.h	(revision 185708)
+++ gcc/config/arm/linux-elf.h	(working copy)
@@ -60,13 +60,17 @@
 #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
 
 #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
+#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
 
 #define LINUX_TARGET_LINK_SPEC  "%{h*} \
    %{static:-Bstatic} \
    %{shared:-shared} \
    %{symbolic:-Bsymbolic} \
    %{rdynamic:-export-dynamic} \
-   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
+   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
+   %{!mfloat-abi: \
+     %{!mhard-float:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
    -X \
    %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
    SUBTARGET_EXTRA_LINK_SPEC

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 3 April 2012 09:06, dann frazier <dann.frazier@canonical.com> wrote:
> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>> On 29/03/12 20:34, dann frazier wrote:
>> > This is an updated version of a patch Debian and Ubuntu are using to
>> > use an alternate linker path for hardfloat binaries. The difference
>> > with this one is that it covers the case where no float flag
>> > was passed in, defaulting to the softfloat path.

Hi Dann.  The change should be in the EABI specific linux-eabi.h
instead of the shared/OABI linux-elf.h.  It breaks support for uClibc
and Bionic by always using the GLIBC loader in hard float mode.  The
final line in the spec is missing a '=hard' and always adds
/lib/ld-linux.so.3.

How about:

2012-04-03  Michael Hope  <michael.hope@linaro.org>

       * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
       (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.


diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8498472 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,12 @@
 /* Use ld-linux.so.3 so that it will be possible to run "classic"
    GNU/Linux binaries on an EABI system.  */
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
"/lib/arm-linux-gnueabihf/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */


which works for the following test cases:
 gcc -mhard-float foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
 gcc -mfloat-abi=hard foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
 gcc -msoft-float foo.c => /lib/ld-linux.so.3
 gcc -mfloat-abi=softfp foo.c => /lib/ld-linux.so.3
 gcc -mbionic => /system/bin/linker
 gcc -mbionic -mhard-float => /system/bin/linker
 gcc -muclibc => /lib/ld-uClibc.so.0
 gcc -muclibc -mhard-float => /lib/ld-uClibc.so.0

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Andrew Haley]

On 04/02/2012 10:06 PM, dann frazier wrote:
> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>> On 29/03/12 20:34, dann frazier wrote:
>>> This is an updated version of a patch Debian and Ubuntu are using to
>>> use an alternate linker path for hardfloat binaries. The difference
>>> with this one is that it covers the case where no float flag
>>> was passed in, defaulting to the softfloat path.
>>>
>>> 2012-03-29  dann frazier <dann.frazier@canonical.com>
>>>
>>> 	* config/arm/linux-elf.h: Use alternate linker path
>>>           for hardfloat ABI
>>>
>>> Index: gcc/config/arm/linux-elf.h
>>> ===================================================================
>>> --- gcc/config/arm/linux-elf.h	(revision 185708)
>>> +++ gcc/config/arm/linux-elf.h	(working copy)
>>> @@ -59,14 +59,21 @@
>>>  
>>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>>  
>>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>>  
>>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>>>     %{static:-Bstatic} \
>>>     %{shared:-shared} \
>>>     %{symbolic:-Bsymbolic} \
>>>     %{rdynamic:-export-dynamic} \
>>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>> +   %{!mfloat-abi: \
>>> +     %{!msoft-float: \
>>> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>>>     -X \
>>>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>>>     SUBTARGET_EXTRA_LINK_SPEC
>>>
>>
>> Looks to me as though this will break the old Linux ABI.  While we've
>> marked that as deprecated, it hasn't been removed as yet.  So I think
>> this patch either needs to wait until that removal has taken place, or
>> provide the relevant updates to maintain the old ABI support.
> 
> Thanks for your review. You're right, this does appear to break the
> old ABI - that was a misunderstanding on my part. I think this fixes
> the problem:

But what about those of us who are using hard-float but not the
Debian liker path?  It'll break, surely.  This looks to be like
it's Debian-specific.

Andrew.


> Index: gcc/config/arm/linux-elf.h
> ===================================================================
> --- gcc/config/arm/linux-elf.h	(revision 185708)
> +++ gcc/config/arm/linux-elf.h	(working copy)
> @@ -60,13 +60,17 @@
>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>  
>  #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>  
>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>     %{static:-Bstatic} \
>     %{shared:-shared} \
>     %{symbolic:-Bsymbolic} \
>     %{rdynamic:-export-dynamic} \
> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
> +   %{!mfloat-abi: \
> +     %{!mhard-float:-dynamic-linker " GNU_USER_DYNAMIC_LINKER "}} \
>     -X \
>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>     SUBTARGET_EXTRA_LINK_SPEC
> 

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 10:29, Andrew Haley wrote:
> On 04/02/2012 10:06 PM, dann frazier wrote:
>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>>> On 29/03/12 20:34, dann frazier wrote:
>>>> This is an updated version of a patch Debian and Ubuntu are using to
>>>> use an alternate linker path for hardfloat binaries. The difference
>>>> with this one is that it covers the case where no float flag
>>>> was passed in, defaulting to the softfloat path.
>>>>
>>>> 2012-03-29  dann frazier <dann.frazier@canonical.com>
>>>>
>>>> 	* config/arm/linux-elf.h: Use alternate linker path
>>>>           for hardfloat ABI
>>>>
>>>> Index: gcc/config/arm/linux-elf.h
>>>> ===================================================================
>>>> --- gcc/config/arm/linux-elf.h	(revision 185708)
>>>> +++ gcc/config/arm/linux-elf.h	(working copy)
>>>> @@ -59,14 +59,21 @@
>>>>  
>>>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>>>  
>>>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>>>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>>>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>>>  
>>>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>>>>     %{static:-Bstatic} \
>>>>     %{shared:-shared} \
>>>>     %{symbolic:-Bsymbolic} \
>>>>     %{rdynamic:-export-dynamic} \
>>>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>>>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>> +   %{!mfloat-abi: \
>>>> +     %{!msoft-float: \
>>>> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>>>>     -X \
>>>>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>>>>     SUBTARGET_EXTRA_LINK_SPEC
>>>>
>>>
>>> Looks to me as though this will break the old Linux ABI.  While we've
>>> marked that as deprecated, it hasn't been removed as yet.  So I think
>>> this patch either needs to wait until that removal has taken place, or
>>> provide the relevant updates to maintain the old ABI support.
>>
>> Thanks for your review. You're right, this does appear to break the
>> old ABI - that was a misunderstanding on my part. I think this fixes
>> the problem:
> 
> But what about those of us who are using hard-float but not the
> Debian liker path?  It'll break, surely.  This looks to be like
> it's Debian-specific.
> 

Are you trying to tell me that some distros are using /lib/ld-linux.so.3
directly for hard-float?  Sigh, you distro guys need to start talking to
each other, rather than just going of inventing things ...

If, so then there's only one way to sort out this mess.

/lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
/lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
/lib/ld-linux.so.3 legacy symlink to one of the above.

Or something of this nature.

All this is outside of GCC's remit though and I'm not in a position to
drive any of it through.

:-( :-( :-(

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Guenther]

On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw <rearnsha@arm.com> wrote:
> On 03/04/12 10:29, Andrew Haley wrote:
>> On 04/02/2012 10:06 PM, dann frazier wrote:
>>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>>>> On 29/03/12 20:34, dann frazier wrote:
>>>>> This is an updated version of a patch Debian and Ubuntu are using to
>>>>> use an alternate linker path for hardfloat binaries. The difference
>>>>> with this one is that it covers the case where no float flag
>>>>> was passed in, defaulting to the softfloat path.
>>>>>
>>>>> 2012-03-29  dann frazier <dann.frazier@canonical.com>
>>>>>
>>>>>    * config/arm/linux-elf.h: Use alternate linker path
>>>>>           for hardfloat ABI
>>>>>
>>>>> Index: gcc/config/arm/linux-elf.h
>>>>> ===================================================================
>>>>> --- gcc/config/arm/linux-elf.h     (revision 185708)
>>>>> +++ gcc/config/arm/linux-elf.h     (working copy)
>>>>> @@ -59,14 +59,21 @@
>>>>>
>>>>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>>>>
>>>>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>>>>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>>>>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>>>>
>>>>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>>>>>     %{static:-Bstatic} \
>>>>>     %{shared:-shared} \
>>>>>     %{symbolic:-Bsymbolic} \
>>>>>     %{rdynamic:-export-dynamic} \
>>>>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>>>>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>>> +   %{!mfloat-abi: \
>>>>> +     %{!msoft-float: \
>>>>> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>>>>>     -X \
>>>>>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>>>>>     SUBTARGET_EXTRA_LINK_SPEC
>>>>>
>>>>
>>>> Looks to me as though this will break the old Linux ABI.  While we've
>>>> marked that as deprecated, it hasn't been removed as yet.  So I think
>>>> this patch either needs to wait until that removal has taken place, or
>>>> provide the relevant updates to maintain the old ABI support.
>>>
>>> Thanks for your review. You're right, this does appear to break the
>>> old ABI - that was a misunderstanding on my part. I think this fixes
>>> the problem:
>>
>> But what about those of us who are using hard-float but not the
>> Debian liker path?  It'll break, surely.  This looks to be like
>> it's Debian-specific.
>>
>
> Are you trying to tell me that some distros are using /lib/ld-linux.so.3
> directly for hard-float?  Sigh, you distro guys need to start talking to
> each other, rather than just going of inventing things ...
>
> If, so then there's only one way to sort out this mess.
>
> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
> /lib/ld-linux.so.3 legacy symlink to one of the above.
>
> Or something of this nature.
>
> All this is outside of GCC's remit though and I'm not in a position to
> drive any of it through.
>
> :-( :-( :-(

Now, I wonder why the dynamic linker cannot figure out the ABI itself
by means of using ELF flags or so?

Richard.

> R.
>
>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 11:51, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw <rearnsha@arm.com> wrote:
>> On 03/04/12 10:29, Andrew Haley wrote:
>>> On 04/02/2012 10:06 PM, dann frazier wrote:
>>>> On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
>>>>> On 29/03/12 20:34, dann frazier wrote:
>>>>>> This is an updated version of a patch Debian and Ubuntu are using to
>>>>>> use an alternate linker path for hardfloat binaries. The difference
>>>>>> with this one is that it covers the case where no float flag
>>>>>> was passed in, defaulting to the softfloat path.
>>>>>>
>>>>>> 2012-03-29  dann frazier <dann.frazier@canonical.com>
>>>>>>
>>>>>>    * config/arm/linux-elf.h: Use alternate linker path
>>>>>>           for hardfloat ABI
>>>>>>
>>>>>> Index: gcc/config/arm/linux-elf.h
>>>>>> ===================================================================
>>>>>> --- gcc/config/arm/linux-elf.h     (revision 185708)
>>>>>> +++ gcc/config/arm/linux-elf.h     (working copy)
>>>>>> @@ -59,14 +59,21 @@
>>>>>>
>>>>>>  #define LIBGCC_SPEC "%{mfloat-abi=soft*:-lfloat} -lgcc"
>>>>>>
>>>>>> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.2"
>>>>>> +#define LINUX_DYNAMIC_LINKER_SF "/lib/ld-linux.so.3"
>>>>>> +#define LINUX_DYNAMIC_LINKER_HF "/lib/arm-linux-gnueabihf/ld-linux.so.3"
>>>>>>
>>>>>>  #define LINUX_TARGET_LINK_SPEC  "%{h*} \
>>>>>>     %{static:-Bstatic} \
>>>>>>     %{shared:-shared} \
>>>>>>     %{symbolic:-Bsymbolic} \
>>>>>>     %{rdynamic:-export-dynamic} \
>>>>>> -   -dynamic-linker " GNU_USER_DYNAMIC_LINKER " \
>>>>>> +   %{msoft-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>>>> +   %{mfloat-abi=soft*:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "} \
>>>>>> +   %{mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>>>> +   %{mfloat-abi=hard:-dynamic-linker " LINUX_DYNAMIC_LINKER_HF "} \
>>>>>> +   %{!mfloat-abi: \
>>>>>> +     %{!msoft-float: \
>>>>>> +       %{!mhard-float:-dynamic-linker " LINUX_DYNAMIC_LINKER_SF "}}} \
>>>>>>     -X \
>>>>>>     %{mbig-endian:-EB} %{mlittle-endian:-EL}" \
>>>>>>     SUBTARGET_EXTRA_LINK_SPEC
>>>>>>
>>>>>
>>>>> Looks to me as though this will break the old Linux ABI.  While we've
>>>>> marked that as deprecated, it hasn't been removed as yet.  So I think
>>>>> this patch either needs to wait until that removal has taken place, or
>>>>> provide the relevant updates to maintain the old ABI support.
>>>>
>>>> Thanks for your review. You're right, this does appear to break the
>>>> old ABI - that was a misunderstanding on my part. I think this fixes
>>>> the problem:
>>>
>>> But what about those of us who are using hard-float but not the
>>> Debian liker path?  It'll break, surely.  This looks to be like
>>> it's Debian-specific.
>>>
>>
>> Are you trying to tell me that some distros are using /lib/ld-linux.so.3
>> directly for hard-float?  Sigh, you distro guys need to start talking to
>> each other, rather than just going of inventing things ...
>>
>> If, so then there's only one way to sort out this mess.
>>
>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>> /lib/ld-linux.so.3 legacy symlink to one of the above.
>>
>> Or something of this nature.
>>
>> All this is outside of GCC's remit though and I'm not in a position to
>> drive any of it through.
>>
>> :-( :-( :-(
> 
> Now, I wonder why the dynamic linker cannot figure out the ABI itself
> by means of using ELF flags or so?
> 

There are no ELF flags for this in executables.  The attributes only
apply to object files and anyway they are too expensive to decode at run
time.

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
> If, so then there's only one way to sort out this mess.
> 
> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader

The above scheme is a Debianism which no other distro is using.

	Jakub

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[dann frazier]

On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
> On 3 April 2012 09:06, dann frazier <dann.frazier@canonical.com> wrote:
> > On Fri, Mar 30, 2012 at 06:52:34PM +0100, Richard Earnshaw wrote:
> >> On 29/03/12 20:34, dann frazier wrote:
> >> > This is an updated version of a patch Debian and Ubuntu are using to
> >> > use an alternate linker path for hardfloat binaries. The difference
> >> > with this one is that it covers the case where no float flag
> >> > was passed in, defaulting to the softfloat path.
> 
> Hi Dann.  The change should be in the EABI specific linux-eabi.h
> instead of the shared/OABI linux-elf.h.  It breaks support for uClibc
> and Bionic by always using the GLIBC loader in hard float mode.  The
> final line in the spec is missing a '=hard' and always adds
> /lib/ld-linux.so.3.
> 
> How about:
> 
> 2012-04-03  Michael Hope  <michael.hope@linaro.org>
> 
>        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>        (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float loader.

Nice, thanks Michael. I'd looked at doing something similar, but I
wasn't sure that defining GLIBC_DYNAMIC_LINKER to a spec macro would
work :)

     -dann
> 
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index 80bd825..8498472 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -62,7 +62,12 @@
>  /* Use ld-linux.so.3 so that it will be possible to run "classic"
>     GNU/Linux binaries on an EABI system.  */
>  #undef  GLIBC_DYNAMIC_LINKER
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
> "/lib/arm-linux-gnueabihf/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
> 
>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
>     use the GNU/Linux version, not the generic BPABI version.  */
> 
> 
> which works for the following test cases:
>  gcc -mhard-float foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -mfloat-abi=hard foo.c => /lib/arm-linux-gnueabihf/ld-linux.so.3
>  gcc -msoft-float foo.c => /lib/ld-linux.so.3
>  gcc -mfloat-abi=softfp foo.c => /lib/ld-linux.so.3
>  gcc -mbionic => /system/bin/linker
>  gcc -mbionic -mhard-float => /system/bin/linker
>  gcc -muclibc => /lib/ld-uClibc.so.0
>  gcc -muclibc -mhard-float => /lib/ld-uClibc.so.0
> 
> -- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 03/04/12 12:01, Jakub Jelinek wrote:
> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>> If, so then there's only one way to sort out this mess.
>>
>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
> 
> The above scheme is a Debianism which no other distro is using.
> 
> 	Jakub
> 

Not really, it's just a naming convention for where the config-specific
dynamic loader lives.  It doesn't affect where the remaining shared
libraries live.

The subdirectories could be called fred and jim and it would still work.
 The only thing required is that this part of the naming scheme be
agreed amongst the distros.

This looks to me like it's turning into a bike-shed painting excerise
between the distros out there.  That's really sad.

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Andrew Haley]

On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
> On 03/04/12 12:01, Jakub Jelinek wrote:
>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>>> If, so then there's only one way to sort out this mess.
>>>
>>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>>
>> The above scheme is a Debianism which no other distro is using.
>>
>> 	Jakub
>>
> 
> Not really, it's just a naming convention for where the config-specific
> dynamic loader lives.  It doesn't affect where the remaining shared
> libraries live.
> 
> The subdirectories could be called fred and jim and it would still work.
>  The only thing required is that this part of the naming scheme be
> agreed amongst the distros.
> 
> This looks to me like it's turning into a bike-shed painting excerise
> between the distros out there.  That's really sad.

I don't think we ever even had the discussion: Debian invented their
Debian-internal scheme for managing multiple ABIs.  They have in the past
used patched versions of gcc, as in the case of x86_64.

Andrew.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 04:17, Andrew Haley <aph@redhat.com> wrote:
> On 04/03/2012 05:09 PM, Richard Earnshaw wrote:
>> On 03/04/12 12:01, Jakub Jelinek wrote:
>>> On Tue, Apr 03, 2012 at 11:45:30AM +0100, Richard Earnshaw wrote:
>>>> If, so then there's only one way to sort out this mess.
>>>>
>>>> /lib/arm-linux-gnueabi/ld-linux.so.3  Location of soft-float loader
>>>> /lib/arm-linux-gnueabihf/ld-linux.so.3 Location of hard-float loader
>>>
>>> The above scheme is a Debianism which no other distro is using.
>>>
>>>      Jakub
>>>
>>
>> Not really, it's just a naming convention for where the config-specific
>> dynamic loader lives.  It doesn't affect where the remaining shared
>> libraries live.
>>
>> The subdirectories could be called fred and jim and it would still work.
>>  The only thing required is that this part of the naming scheme be
>> agreed amongst the distros.
>>
>> This looks to me like it's turning into a bike-shed painting excerise
>> between the distros out there.  That's really sad.
>
> I don't think we ever even had the discussion: Debian invented their
> Debian-internal scheme for managing multiple ABIs.  They have in the past
> used patched versions of gcc, as in the case of x86_64.

(cc'ed cross-distro as the discussion is also going on there[1].  This
patch continues that)

I like the idea of incompatible binaries having different loaders.
The path doesn't matter but the concept does.  Like i686/x86_64, it
gives distros the option to install different binaries alongside each
other for compatibility, performance, or upgrade reasons.  The
compatibility cost is nice and low and lets Debian do some interesting
cross development things.

No one has released a hard float based distro yet.  We have time to
discuss and fix this so we don't get in the crazy situation where a
third party binary only runs on some distros.

-- Michael

[1] http://lists.linaro.org/pipermail/cross-distro/2012-March/000135.html
and http://lists.linaro.org/pipermail/cross-distro/2012-April/thread.html

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Joseph S. Myers]

On Tue, 3 Apr 2012, Michael Hope wrote:

> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"

(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to 
be handled in specs.

(b) You need to handle compilers configured with --with-float=hard, so 
make the specs depend on the default ABI the compiler was configured with.

(c) Please include libc-ports on future submissions and provide both the 
GCC patch and the glibc ports patch that have been tested to work together 
to build and install the library in the given path; a patch to one 
component like this cannot sensibly be considered in isolation.  I imagine 
you'll need appropriate ARM preconfigure support to detect what ABI the 
compiler is using, much like the support for MIPS, so that the right 
shlib-versions files are used.  I try to follow all ARM glibc discussions 
on libc-ports closely, as the ARM glibc maintainer; was there a previous 
discussion of the dynamic linker naming issue there that I missed?  (The 
only previous relevant discussion that I recall is one on 
patches@eglibc.org starting at 
<http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the 
dynamic linker should check that a library has the right ABI, and there 
was no real followup on that after I indicated what would seem to be the 
appropriate implementation approaches and places for subsequent 
discussion.)

I have no idea whether shlib-versions files naming a file in a 
subdirectory will work - but if not, you'd need to send a patch to 
libc-alpha to support dynamic linkers in subdirectories, with appropriate 
justification for why you are doing something different from all other 
architectures.

(d) Existing practice for Power Architecture and MIPS at least is that 
hard-float and soft-float *don't* use different library directories / 
dynamic linkers.

(e) Existing practice for cases that do use different dynamic linkers is 
to use a separate library directory, not just dynamic linker name, as in 
lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to 
make two sets of libraries work in parallel if you have separate library 
directories like that.  So it would seem more appropriate to define a 
directory libhf for ARM (meaning you need a binutils patch as well to 
handle that directory, I think), and these different Debian-style names 
could be implemented separately in a multiarch patch if someone submits 
one that properly accounts for my review comments on previous patch 
versions (failure to produce such a fixed patch being why Debian multiarch 
directory support has not got into GCC so far).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
> >> The subdirectories could be called fred and jim and it would still work.
> >>  The only thing required is that this part of the naming scheme be
> >> agreed amongst the distros.
> >>
> >> This looks to me like it's turning into a bike-shed painting excerise
> >> between the distros out there.  That's really sad.
> >
> > I don't think we ever even had the discussion: Debian invented their
> > Debian-internal scheme for managing multiple ABIs.  They have in the past
> > used patched versions of gcc, as in the case of x86_64.
> 
> (cc'ed cross-distro as the discussion is also going on there[1].  This
> patch continues that)
> 
> I like the idea of incompatible binaries having different loaders.
> The path doesn't matter but the concept does.  Like i686/x86_64, it
> gives distros the option to install different binaries alongside each
> other for compatibility, performance, or upgrade reasons.  The
> compatibility cost is nice and low and lets Debian do some interesting
> cross development things.

Does the dynamic linker itself contain any routines that depend on the
soft/hard ABI?  That would quite surprise me, so I don't see the point of
having different dynamic linkers for those ABIs.  One dynamic linker should
handle both just fine.

> No one has released a hard float based distro yet.  We have time to
> discuss and fix this so we don't get in the crazy situation where a
> third party binary only runs on some distros.

Isn't e.g. Fedora 17/armv7hl a hard float based distro?

	Jakub

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 11:11, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>> >> The subdirectories could be called fred and jim and it would still work.
>> >>  The only thing required is that this part of the naming scheme be
>> >> agreed amongst the distros.
>> >>
>> >> This looks to me like it's turning into a bike-shed painting excerise
>> >> between the distros out there.  That's really sad.
>> >
>> > I don't think we ever even had the discussion: Debian invented their
>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>> > used patched versions of gcc, as in the case of x86_64.
>>
>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>> patch continues that)
>>
>> I like the idea of incompatible binaries having different loaders.
>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>> gives distros the option to install different binaries alongside each
>> other for compatibility, performance, or upgrade reasons.  The
>> compatibility cost is nice and low and lets Debian do some interesting
>> cross development things.
>
> Does the dynamic linker itself contain any routines that depend on the
> soft/hard ABI?  That would quite surprise me, so I don't see the point of
> having different dynamic linkers for those ABIs.  One dynamic linker should
> handle both just fine.
>
>> No one has released a hard float based distro yet.  We have time to
>> discuss and fix this so we don't get in the crazy situation where a
>> third party binary only runs on some distros.
>
> Isn't e.g. Fedora 17/armv7hl a hard float based distro?

Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
None have been released yet.  Here's my understanding:

Fedora 17:
 * ARM is a secondary architecture
 * Alpha 1 release is out
 * Has both a ARMv5 soft float and ARMv7 hard float build

Ubuntu Precise:
 * ARM is a primary architecture
 * Beta 2 is out
 * ARMv7 hard float by default with ARMv7 softfp being community supported

Debian:
 * ARM is a primary architecture
 * Has a ARMv4T soft float and in-development ARMv7 hard float

openSUSE:
 * Kicked off at a hackfest in September 2011
 * Have a ARMv5T soft float and ARMv7 hard float build

Gentoo:
 * I'm unsure (help?)
 * The Gentoo manual suggests ARMv7 softfp is the default

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Peter Robinson]

On Wed, Apr 4, 2012 at 12:48 AM, Michael Hope <michael.hope@linaro.org> wrote:
> On 4 April 2012 11:11, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >>  The only thing required is that this part of the naming scheme be
>>> >> agreed amongst the distros.
>>> >>
>>> >> This looks to me like it's turning into a bike-shed painting excerise
>>> >> between the distros out there.  That's really sad.
>>> >
>>> > I don't think we ever even had the discussion: Debian invented their
>>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>>> > used patched versions of gcc, as in the case of x86_64.
>>>
>>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>>> patch continues that)
>>>
>>> I like the idea of incompatible binaries having different loaders.
>>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>>> gives distros the option to install different binaries alongside each
>>> other for compatibility, performance, or upgrade reasons.  The
>>> compatibility cost is nice and low and lets Debian do some interesting
>>> cross development things.
>>
>> Does the dynamic linker itself contain any routines that depend on the
>> soft/hard ABI?  That would quite surprise me, so I don't see the point of
>> having different dynamic linkers for those ABIs.  One dynamic linker should
>> handle both just fine.
>>
>>> No one has released a hard float based distro yet.  We have time to
>>> discuss and fix this so we don't get in the crazy situation where a
>>> third party binary only runs on some distros.
>>
>> Isn't e.g. Fedora 17/armv7hl a hard float based distro?
>
> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
> None have been released yet.  Here's my understanding:
>
> Fedora 17:
>  * ARM is a secondary architecture
>  * Alpha 1 release is out
>  * Has both a ARMv5 soft float and ARMv7 hard float build

Beta isn't far off and we're working toward Primary Arch.

> Ubuntu Precise:
>  * ARM is a primary architecture
>  * Beta 2 is out
>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>
> Debian:
>  * ARM is a primary architecture
>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>
> openSUSE:
>  * Kicked off at a hackfest in September 2011
>  * Have a ARMv5T soft float and ARMv7 hard float build

Is only hard float, they haven't ruled out doing v5 soft float but
it's not their current focus.

Peter

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Paulo César Pereira de Andrade]

Em 3 de abril de 2012 20:48, Michael Hope <michael.hope@linaro.org> escreveu:
> On 4 April 2012 11:11, Jakub Jelinek <jakub@redhat.com> wrote:
>> On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>>> >> The subdirectories could be called fred and jim and it would still work.
>>> >>  The only thing required is that this part of the naming scheme be
>>> >> agreed amongst the distros.
>>> >>
>>> >> This looks to me like it's turning into a bike-shed painting excerise
>>> >> between the distros out there.  That's really sad.
>>> >
>>> > I don't think we ever even had the discussion: Debian invented their
>>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>>> > used patched versions of gcc, as in the case of x86_64.
>>>
>>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>>> patch continues that)
>>>
>>> I like the idea of incompatible binaries having different loaders.
>>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>>> gives distros the option to install different binaries alongside each
>>> other for compatibility, performance, or upgrade reasons.  The
>>> compatibility cost is nice and low and lets Debian do some interesting
>>> cross development things.
>>
>> Does the dynamic linker itself contain any routines that depend on the
>> soft/hard ABI?  That would quite surprise me, so I don't see the point of
>> having different dynamic linkers for those ABIs.  One dynamic linker should
>> handle both just fine.
>>
>>> No one has released a hard float based distro yet.  We have time to
>>> discuss and fix this so we don't get in the crazy situation where a
>>> third party binary only runs on some distros.
>>
>> Isn't e.g. Fedora 17/armv7hl a hard float based distro?
>
> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
> None have been released yet.  Here's my understanding:
>
> Fedora 17:
>  * ARM is a secondary architecture
>  * Alpha 1 release is out
>  * Has both a ARMv5 soft float and ARMv7 hard float build
>
> Ubuntu Precise:
>  * ARM is a primary architecture
>  * Beta 2 is out
>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>
> Debian:
>  * ARM is a primary architecture
>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>
> openSUSE:
>  * Kicked off at a hackfest in September 2011
>  * Have a ARMv5T soft float and ARMv7 hard float build
>
> Gentoo:
>  * I'm unsure (help?)
>  * The Gentoo manual suggests ARMv7 softfp is the default

  I did two ports of Mandriva to armv7. One of my choice to use softfp,
and another hardfp port to be compatible with other distros. But other
than a previous armv5 port, there is not much else of Mandriva arm,
so, it would be "good to have" to be able to run binaries for either
without resorting to a chroot, and only testing purposes.

  Bumping major or calling it ld-linux-foo.so.3 is out of question?

> -- Michael
>
> _______________________________________________
> cross-distro mailing list
> cross-distro@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

2012/4/4 Paulo César Pereira de Andrade
<paulo.cesar.pereira.de.andrade@gmail.com>:
> Em 3 de abril de 2012 20:48, Michael Hope <michael.hope@linaro.org> escreveu:

<snip>

>> Yip, as is Ubuntu Precise, Debian unstable, and a skew of Gentoo.
>> None have been released yet.  Here's my understanding:
>>
>> Fedora 17:
>>  * ARM is a secondary architecture
>>  * Alpha 1 release is out
>>  * Has both a ARMv5 soft float and ARMv7 hard float build
>>
>> Ubuntu Precise:
>>  * ARM is a primary architecture
>>  * Beta 2 is out
>>  * ARMv7 hard float by default with ARMv7 softfp being community supported
>>
>> Debian:
>>  * ARM is a primary architecture
>>  * Has a ARMv4T soft float and in-development ARMv7 hard float
>>
>> openSUSE:
>>  * Kicked off at a hackfest in September 2011
>>  * Have a ARMv5T soft float and ARMv7 hard float build
>>
>> Gentoo:
>>  * I'm unsure (help?)
>>  * The Gentoo manual suggests ARMv7 softfp is the default
>
>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> and another hardfp port to be compatible with other distros. But other
> than a previous armv5 port, there is not much else of Mandriva arm,
> so, it would be "good to have" to be able to run binaries for either
> without resorting to a chroot, and only testing purposes.
>
>  Bumping major or calling it ld-linux-foo.so.3 is out of question?

I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
questions here though: can the hard float loader have a different path
and, if so, what should it be?  We're still working on the first part.

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 10:56, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Tue, 3 Apr 2012, Michael Hope wrote:
>
>> +#define GLIBC_DYNAMIC_LINKER \
>> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
>> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
>
> (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
> be handled in specs.

Fixed.

> (b) You need to handle compilers configured with --with-float=hard, so
> make the specs depend on the default ABI the compiler was configured with.

GCC seems to take configure time options into account when evaluating
a spec file.

Tested by building a default, --with-float=hard, and
--with-float=softfp compiler then checking the loader path for all
combinations of {,-mglibc,-mbionic,-muclibc} x
{,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.

> (c) Please include libc-ports on future submissions and provide both the
> GCC patch and the glibc ports patch that have been tested to work together
> to build and install the library in the given path; a patch to one
> component like this cannot sensibly be considered in isolation.  I imagine
> you'll need appropriate ARM preconfigure support to detect what ABI the
> compiler is using, much like the support for MIPS, so that the right
> shlib-versions files are used.

Agreed.

>  I try to follow all ARM glibc discussions
> on libc-ports closely, as the ARM glibc maintainer; was there a previous
> discussion of the dynamic linker naming issue there that I missed?

Steve McIntyre is driving this inside Debian.  I'll ping him on the
GLIBC support.

The tricky one is new GCC with old GLIBC.  GCC may have to do a
configure time test and fall back to /lib/ld-linux.so.3 if the hard
float loader is missing.

>  (The only previous relevant discussion that I recall is one on
> patches@eglibc.org starting at
> <http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the
> dynamic linker should check that a library has the right ABI, and there
> was no real followup on that after I indicated what would seem to be the
> appropriate implementation approaches and places for subsequent
> discussion.)

The patch above changes the loader to catch a mixed installation and
reject mixing incompatible libraries.  The static linker does this
currently but it's not essential.

> I have no idea whether shlib-versions files naming a file in a
> subdirectory will work - but if not, you'd need to send a patch to
> libc-alpha to support dynamic linkers in subdirectories, with appropriate
> justification for why you are doing something different from all other
> architectures.

Understood.  For now this is just a path.  There's more infrastructure
work needed if the path includes a directory.

> (d) Existing practice for Power Architecture and MIPS at least is that
> hard-float and soft-float *don't* use different library directories /
> dynamic linkers.

The goal is to have a standard loader path for all hard float distros
and, similar to how you can have a mixed 32/64 bit installation, allow
mixed softfp/hard float installations for distros that want it.  This
is a new requirement and ARM is the first one exposed to it.  I assume
Debian would push for similar changes on MIPS and PowerPC.

Do the MIPS or PowerPC loaders detect the ABI and change the library
path based on that?  I couldn't tell from the code.

> (e) Existing practice for cases that do use different dynamic linkers is
> to use a separate library directory, not just dynamic linker name, as in
> lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
> make two sets of libraries work in parallel if you have separate library
> directories like that.

Is this required, or should it be left to the distro to choose?  Once
the loader is in control then it can account for any distro specific
features, which may be the standard /lib and /usr/lib for single ABI
distros like Fedora or /usr/lib/$tuple for multiarch distros like
Ubuntu and Debian.

> So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to
> handle that directory, I think)

I'd like to leave that discussion for now.  The Debian goal is to
support incompatible ABIs and, past that, incompatible architectures.
libhf is ambiguous as you could have a MIPS hard float library
installed on the same system as an ARM hard float library.

> and these different Debian-style names
> could be implemented separately in a multiarch patch if someone submits
> one that properly accounts for my review comments on previous patch
> versions (failure to produce such a fixed patch being why Debian multiarch
> directory support has not got into GCC so far).

Agreed.  Note that this loader path discussion is unrelated to
multiarch.  It came from the same people so there's a family
resemblance.

(BTW Dann, apologies for stealing your patch)

-- Michael

2012-04-03  Michael Hope  <michael.hope@linaro.org>

       * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
       (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.

diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
index 80bd825..8c9d2e7 100644
--- a/gcc/config/arm/linux-eabi.h
+++ b/gcc/config/arm/linux-eabi.h
@@ -62,7 +62,11 @@
 /* Use ld-linux.so.3 so that it will be possible to run "classic"
    GNU/Linux binaries on an EABI system.  */
 #undef  GLIBC_DYNAMIC_LINKER
-#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
"/lib/arm-linux-gnueabihf/ld-linux.so.3"
+#define GLIBC_DYNAMIC_LINKER \
+   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
+    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"

 /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
    use the GNU/Linux version, not the generic BPABI version.  */

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> >  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> > and another hardfp port to be compatible with other distros. But other
> > than a previous armv5 port, there is not much else of Mandriva arm,
> > so, it would be "good to have" to be able to run binaries for either
> > without resorting to a chroot, and only testing purposes.
> >
> >  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> 
> I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> questions here though: can the hard float loader have a different path
> and, if so, what should it be?  We're still working on the first part.

If the agreement is that arm 32-bit softfp really needs to be installable
alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
various MIPS variants) and what FSB says, e.g. use
/lib/ld-linux.so.3 and */lib dirs for softfp,
/libhf/ld-linux.so.3 and */libhf dirs for hardfp and
/lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that
choose the Debian layout instead, if it is added somehow configurable into
upstream gcc/glibc of course handle it similarly there.  I just wonder why
that hasn't been done 10 years ago and only needs doing now (of course,
aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).

One needs to wonder also why arm hasn't switched to 128-bit long double when
all other mainstream architectures did (I hope at least aarch64 will use it
by default).

	Jakub

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Andrew Haley]

On 04/03/2012 11:53 AM, Richard Earnshaw wrote:
>> Now, I wonder why the dynamic linker cannot figure out the ABI itself
>> > by means of using ELF flags or so?
>> > 
> There are no ELF flags for this in executables.  The attributes only
> apply to object files and anyway they are too expensive to decode at run
> time.

Isn't that the core problem, then?  We have incompatible libraries
and executables but they aren't marked as such.

Andrew.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Joseph S. Myers]

On Wed, 4 Apr 2012, Michael Hope wrote:

> The tricky one is new GCC with old GLIBC.  GCC may have to do a
> configure time test and fall back to /lib/ld-linux.so.3 if the hard
> float loader is missing.

I don't think that's appropriate for ABI issues.  If a different dynamic 
linker name is specified, GCC should use it unconditionally (and require 
new enough glibc or a glibc installation that was appropriately 
rearranged).

> > I have no idea whether shlib-versions files naming a file in a
> > subdirectory will work - but if not, you'd need to send a patch to
> > libc-alpha to support dynamic linkers in subdirectories, with appropriate
> > justification for why you are doing something different from all other
> > architectures.
> 
> Understood.  For now this is just a path.  There's more infrastructure
> work needed if the path includes a directory.

Formally it's just a path - but an important feature of GNU/Linux and the 
GNU toolchain is consistency between different architectures and existing 
upstream practice is that the dynamic linker is always in the same 
directory as the other associated libraries and that this has the form 
/lib<something>.  In the absence of a compelling reason, which I have not 
seen stated, to do otherwise for a single case, I think that existing 
practice should be followed with the dynamic linker being in a directory 
such as /libhf.

The "more infrastructure work needed" makes clear that you need libc-alpha 
buy-in *before* putting any patches into GCC or ports.  But maybe if you 
don't try to put the dynamic linker in a different directory from the 
other libraries, it's easier to support via existing mechanisms (setting 
slibdir differently if --enable-multiarch-directories or similar)?

> Do the MIPS or PowerPC loaders detect the ABI and change the library
> path based on that?  I couldn't tell from the code.

No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and 
e500v2 variants - compatible with soft-float at the function-calling level 
but with some glibc ABI differences with soft-float and with each other) 
use the same directories.

> > (e) Existing practice for cases that do use different dynamic linkers is
> > to use a separate library directory, not just dynamic linker name, as in
> > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
> > make two sets of libraries work in parallel if you have separate library
> > directories like that.
> 
> Is this required, or should it be left to the distro to choose?  Once
> the loader is in control then it can account for any distro specific
> features, which may be the standard /lib and /usr/lib for single ABI
> distros like Fedora or /usr/lib/$tuple for multiarch distros like
> Ubuntu and Debian.

I thought Fedora used the standard upstream /lib64 on x86_64 and so would 
naturally use a standard upstream /libhf where appropriate.

> > So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to
> > handle that directory, I think)
> 
> I'd like to leave that discussion for now.  The Debian goal is to
> support incompatible ABIs and, past that, incompatible architectures.
> libhf is ambiguous as you could have a MIPS hard float library
> installed on the same system as an ARM hard float library.

If you want both ARM and MIPS hard-float then I'd think you want both 
big-endian and little-endian ARM hard-float - but your patch defines the 
same dynamic linker name for both of those.

Standard upstream practice supports having multiple variants that 
plausibly run on the same system at the same time, such as /lib and 
/lib64, and it seems reasonable to support hard and soft float variants 
that way via a directory such as /libhf.  The Debian-style paths are not 
the default on any other architecture and I don't think it's appropriate 
to make them the default for this particular case only.

> > and these different Debian-style names
> > could be implemented separately in a multiarch patch if someone submits
> > one that properly accounts for my review comments on previous patch
> > versions (failure to produce such a fixed patch being why Debian multiarch
> > directory support has not got into GCC so far).
> 
> Agreed.  Note that this loader path discussion is unrelated to
> multiarch.  It came from the same people so there's a family
> resemblance.

I think it's directly related, and that such a path is inappropriate by 
default; that ARM should be consistent with other architectures, and that 
if you want to support paths in such subdirectories that would be a 
separate multiarch patch series for GCC, binutils and glibc (but the 
PT_INTERP would still use /lib<whatever>/<name> without subdirectories in 
any case).

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Joseph S. Myers]

On Wed, 4 Apr 2012, Jakub Jelinek wrote:

> If the agreement is that arm 32-bit softfp really needs to be installable
> alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
> like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
> various MIPS variants) and what FSB says, e.g. use
> /lib/ld-linux.so.3 and */lib dirs for softfp,
> /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those that
> choose the Debian layout instead, if it is added somehow configurable into
> upstream gcc/glibc of course handle it similarly there.  I just wonder why
> that hasn't been done 10 years ago and only needs doing now (of course,
> aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).

Exactly.  The default should follow the existing practice for other 
architectures.

> One needs to wonder also why arm hasn't switched to 128-bit long double when
> all other mainstream architectures did (I hope at least aarch64 will use it
> by default).

The AArch64 ABI (generic, not GNU/Linux, and draft, still subject to 
incompatible change) is public and used 128-bit long double the last time 
I checked.

My presumption is that there has been no demand for long double wider than 
double among 32-bit ARM users.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Dennis Gilmore]

On Wed, 4 Apr 2012 09:06:05 +0000 (UTC)
"Joseph S. Myers" <joseph@codesourcery.com> wrote:

> On Wed, 4 Apr 2012, Michael Hope wrote:
> 
> > The tricky one is new GCC with old GLIBC.  GCC may have to do a
> > configure time test and fall back to /lib/ld-linux.so.3 if the hard
> > float loader is missing.
> 
> I don't think that's appropriate for ABI issues.  If a different
> dynamic linker name is specified, GCC should use it unconditionally
> (and require new enough glibc or a glibc installation that was
> appropriately rearranged).
> 
> > > I have no idea whether shlib-versions files naming a file in a
> > > subdirectory will work - but if not, you'd need to send a patch to
> > > libc-alpha to support dynamic linkers in subdirectories, with
> > > appropriate justification for why you are doing something
> > > different from all other architectures.
> > 
> > Understood.  For now this is just a path.  There's more
> > infrastructure work needed if the path includes a directory.
> 
> Formally it's just a path - but an important feature of GNU/Linux and
> the GNU toolchain is consistency between different architectures and
> existing upstream practice is that the dynamic linker is always in
> the same directory as the other associated libraries and that this
> has the form /lib<something>.  In the absence of a compelling reason,
> which I have not seen stated, to do otherwise for a single case, I
> think that existing practice should be followed with the dynamic
> linker being in a directory such as /libhf.

Consistency across architectures is why Fedora does many of the things
the way it does,  It really doesn't make much sense to me to diverge
from that.

> The "more infrastructure work needed" makes clear that you need
> libc-alpha buy-in *before* putting any patches into GCC or ports.
> But maybe if you don't try to put the dynamic linker in a different
> directory from the other libraries, it's easier to support via
> existing mechanisms (setting slibdir differently if
> --enable-multiarch-directories or similar)?
> 
> > Do the MIPS or PowerPC loaders detect the ABI and change the library
> > path based on that?  I couldn't tell from the code.
> 
> No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1
> and e500v2 variants - compatible with soft-float at the
> function-calling level but with some glibc ABI differences with
> soft-float and with each other) use the same directories.
> 
> > > (e) Existing practice for cases that do use different dynamic
> > > linkers is to use a separate library directory, not just dynamic
> > > linker name, as in lib32 and lib64 for MIPS or libx32 for x32;
> > > it's certainly a lot easier to make two sets of libraries work in
> > > parallel if you have separate library directories like that.
> > 
> > Is this required, or should it be left to the distro to choose?
> > Once the loader is in control then it can account for any distro
> > specific features, which may be the standard /lib and /usr/lib for
> > single ABI distros like Fedora or /usr/lib/$tuple for multiarch
> > distros like Ubuntu and Debian.
> 
> I thought Fedora used the standard upstream /lib64 on x86_64 and so
> would naturally use a standard upstream /libhf where appropriate.

Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
wouldn't object to /libhf  though today we have f17 about to go beta
and all of rawhide built using /lib 

Fedora also has software floating point being installed into /lib also 

> > > So it would seem more appropriate to define a directory libhf for
> > > ARM (meaning you need a binutils patch as well to handle that
> > > directory, I think)


Dennis

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 18:54, Jakub Jelinek <jakub@redhat.com> wrote:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>> >  I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> > and another hardfp port to be compatible with other distros. But other
>> > than a previous armv5 port, there is not much else of Mandriva arm,
>> > so, it would be "good to have" to be able to run binaries for either
>> > without resorting to a chroot, and only testing purposes.
>> >
>> >  Bumping major or calling it ld-linux-foo.so.3 is out of question?
>>
>> I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
>> questions here though: can the hard float loader have a different path
>> and, if so, what should it be?  We're still working on the first part.
>
> If the agreement is that arm 32-bit softfp really needs to be installable
> alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
> like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
> various MIPS variants) and what FSB says, e.g. use
> /lib/ld-linux.so.3 and */lib dirs for softfp,
> /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> MULTILIB_OSDIRNAMES, etc., have it configured in glibc

OK.  This gives a different path for the hard float loader and lets
the Debian guys add on top of that.  I'll ping them and see what they
think.

> and for those that
> choose the Debian layout instead, if it is added somehow configurable into
> upstream gcc/glibc of course handle it similarly there.

Agreed.

> I just wonder why that hasn't been done 10 years ago and only needs doing now

FPUs have only become common on ARM in the last few years.  softfp was
a good interim work around but performance is significantly better
with hard float.

> (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).

Yip.  I assume something like /lib64 to stay consistent with other
architectures.  aarch64 is hard float only.

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 4 April 2012 21:06, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Wed, 4 Apr 2012, Michael Hope wrote:
>
>> The tricky one is new GCC with old GLIBC.  GCC may have to do a
>> configure time test and fall back to /lib/ld-linux.so.3 if the hard
>> float loader is missing.
>
> I don't think that's appropriate for ABI issues.  If a different dynamic
> linker name is specified, GCC should use it unconditionally (and require
> new enough glibc or a glibc installation that was appropriately
> rearranged).

OK.  I want GCC 4.7.1 to use the new path.  Does this mean that
released versions of GLIBC and GCC 4.7.1 will be incompatible, or does
GLIBC pick the path up from GCC?

>> > I have no idea whether shlib-versions files naming a file in a
>> > subdirectory will work - but if not, you'd need to send a patch to
>> > libc-alpha to support dynamic linkers in subdirectories, with appropriate
>> > justification for why you are doing something different from all other
>> > architectures.
>>
>> Understood.  For now this is just a path.  There's more infrastructure
>> work needed if the path includes a directory.
>
> Formally it's just a path - but an important feature of GNU/Linux and the
> GNU toolchain is consistency between different architectures and existing
> upstream practice is that the dynamic linker is always in the same
> directory as the other associated libraries and that this has the form
> /lib<something>.  In the absence of a compelling reason, which I have not
> seen stated, to do otherwise for a single case, I think that existing
> practice should be followed with the dynamic linker being in a directory
> such as /libhf.

OK.  This matches Jakub's email.

> The "more infrastructure work needed" makes clear that you need libc-alpha
> buy-in *before* putting any patches into GCC or ports.

OK.  I'm glad we had this discussion as it had to start somewhere.
I'll do a follow up across gcc-patches, libc-alpha, and binutils.

> But maybe if you
> don't try to put the dynamic linker in a different directory from the
> other libraries, it's easier to support via existing mechanisms (setting
> slibdir differently if --enable-multiarch-directories or similar)?

OK.  /libhf may fit that better.

>> Do the MIPS or PowerPC loaders detect the ABI and change the library
>> path based on that?  I couldn't tell from the code.
>
> No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and
> e500v2 variants - compatible with soft-float at the function-calling level
> but with some glibc ABI differences with soft-float and with each other)
> use the same directories.

Sorry, I'm confused.  I had a poke about with MIPS and it uses
different argument registers for soft and hard float.  Soft float uses
$4 and hard float $f0.  Are there shims or similar installed by the
loader?

>> > (e) Existing practice for cases that do use different dynamic linkers is
>> > to use a separate library directory, not just dynamic linker name, as in
>> > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
>> > make two sets of libraries work in parallel if you have separate library
>> > directories like that.
>>
>> Is this required, or should it be left to the distro to choose?  Once
>> the loader is in control then it can account for any distro specific
>> features, which may be the standard /lib and /usr/lib for single ABI
>> distros like Fedora or /usr/lib/$tuple for multiarch distros like
>> Ubuntu and Debian.
>
> I thought Fedora used the standard upstream /lib64 on x86_64 and so would
> naturally use a standard upstream /libhf where appropriate.

Good.  Dennis said the same.

>> > So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to
>> > handle that directory, I think)
>>
>> I'd like to leave that discussion for now.  The Debian goal is to
>> support incompatible ABIs and, past that, incompatible architectures.
>> libhf is ambiguous as you could have a MIPS hard float library
>> installed on the same system as an ARM hard float library.
>
> If you want both ARM and MIPS hard-float then I'd think you want both
> big-endian and little-endian ARM hard-float - but your patch defines the
> same dynamic linker name for both of those.

Big endian is extremely uncommon on ARM and I'd rather define it when
needed.  For strictness sake I'll change the patch to use the new path
for hard float little endian only.

So:
 * Big endian: undefined, defaults to /lib/ld-linux.so.3
 * Little endian, soft float: /lib/ld-linux.so.3
 * Little endian, hard float: /libhf/ld-linux.so.3

> Standard upstream practice supports having multiple variants that
> plausibly run on the same system at the same time, such as /lib and
> /lib64, and it seems reasonable to support hard and soft float variants
> that way via a directory such as /libhf.  The Debian-style paths are not
> the default on any other architecture and I don't think it's appropriate
> to make them the default for this particular case only.

OK.  Debian multiarch covers libraries and headers but not
executables.  As a MIPS hard float /usr/bin/ls would collide with an
ARM hard float /usr/bin/ls then it's fine for the loader names to
potentially collide as well.

In practice they wouldn't as most architecture has a subtily different
loader name (cf. ld.so.1 for MIPS, ld-linux.so.2 for i386, and
ld-linux.so.3 for ARM).

>> > and these different Debian-style names
>> > could be implemented separately in a multiarch patch if someone submits
>> > one that properly accounts for my review comments on previous patch
>> > versions (failure to produce such a fixed patch being why Debian multiarch
>> > directory support has not got into GCC so far).
>>
>> Agreed.  Note that this loader path discussion is unrelated to
>> multiarch.  It came from the same people so there's a family
>> resemblance.
>
> I think it's directly related, and that such a path is inappropriate by
> default; that ARM should be consistent with other architectures, and that
> if you want to support paths in such subdirectories that would be a
> separate multiarch patch series for GCC, binutils and glibc (but the
> PT_INTERP would still use /lib<whatever>/<name> without subdirectories in
> any case).

OK.  I'll ping the Debian guys to see if there's an advantage that I'm missing.

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Joseph S. Myers]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1938 bytes --]

On Thu, 5 Apr 2012, Michael Hope wrote:

> > I don't think that's appropriate for ABI issues.  If a different dynamic
> > linker name is specified, GCC should use it unconditionally (and require
> > new enough glibc or a glibc installation that was appropriately
> > rearranged).
> 
> OK.  I want GCC 4.7.1 to use the new path.  Does this mean that
> released versions of GLIBC and GCC 4.7.1 will be incompatible, or does
> GLIBC pick the path up from GCC?

Released versions would be incompatible (you could make GCC check at 
configure time for too-old glibc if --with-float=hard); the path needs 
hardcoding in both places.

> >> Do the MIPS or PowerPC loaders detect the ABI and change the library
> >> path based on that?  I couldn't tell from the code.
> >
> > No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and
> > e500v2 variants - compatible with soft-float at the function-calling level
> > but with some glibc ABI differences with soft-float and with each other)
> > use the same directories.
> 
> Sorry, I'm confused.  I had a poke about with MIPS and it uses
> different argument registers for soft and hard float.  Soft float uses
> $4 and hard float $f0.  Are there shims or similar installed by the
> loader?

No.  A system is either purely hard-float or purely soft-float, and the 
same paths are used for both so they can't coexist.  (Mismatches at 
*static* link time are detected through object attributes.)

> Big endian is extremely uncommon on ARM and I'd rather define it when
> needed.  For strictness sake I'll change the patch to use the new path
> for hard float little endian only.

I don't think that's correct; the new path should be used independent of 
endian, just as the existing path is.  But any multiarch support patch 
should presumably define separate multiarch paths for each endianness.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Hope]

On 5 April 2012 12:07, Joseph S. Myers <joseph@codesourcery.com> wrote:
> On Thu, 5 Apr 2012, Michael Hope wrote:
>
>> > I don't think that's appropriate for ABI issues.  If a different dynamic
>> > linker name is specified, GCC should use it unconditionally (and require
>> > new enough glibc or a glibc installation that was appropriately
>> > rearranged).
>>
>> OK.  I want GCC 4.7.1 to use the new path.  Does this mean that
>> released versions of GLIBC and GCC 4.7.1 will be incompatible, or does
>> GLIBC pick the path up from GCC?
>
> Released versions would be incompatible (you could make GCC check at
> configure time for too-old glibc if --with-float=hard); the path needs
> hardcoding in both places.
>
>> >> Do the MIPS or PowerPC loaders detect the ABI and change the library
>> >> path based on that?  I couldn't tell from the code.
>> >
>> > No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and
>> > e500v2 variants - compatible with soft-float at the function-calling level
>> > but with some glibc ABI differences with soft-float and with each other)
>> > use the same directories.
>>
>> Sorry, I'm confused.  I had a poke about with MIPS and it uses
>> different argument registers for soft and hard float.  Soft float uses
>> $4 and hard float $f0.  Are there shims or similar installed by the
>> loader?
>
> No.  A system is either purely hard-float or purely soft-float, and the
> same paths are used for both so they can't coexist.  (Mismatches at
> *static* link time are detected through object attributes.)

Ah, the same as ARM then.  The MIPS community would need something
similar to this patch if they wanted to support soft and hard float
side by side.

>> Big endian is extremely uncommon on ARM and I'd rather define it when
>> needed.  For strictness sake I'll change the patch to use the new path
>> for hard float little endian only.
>
> I don't think that's correct; the new path should be used independent of
> endian, just as the existing path is.

OK.

> But any multiarch support patch
> should presumably define separate multiarch paths for each endianness.

That's up to Debian.  I've asked for documentation on the final tuples
and what they mean as the one at:
 http://wiki.debian.org/Multiarch/Tuples

is out of date.  I prefer defining what is needed now and doing others
as needed.

-- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[dann frazier]

On Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote:
> On 4 April 2012 10:56, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Tue, 3 Apr 2012, Michael Hope wrote:
> >
> >> +#define GLIBC_DYNAMIC_LINKER \
> >> +   "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> +    %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> +    %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"
> >
> > (a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to
> > be handled in specs.
> 
> Fixed.
> 
> > (b) You need to handle compilers configured with --with-float=hard, so
> > make the specs depend on the default ABI the compiler was configured with.
> 
> GCC seems to take configure time options into account when evaluating
> a spec file.
> 
> Tested by building a default, --with-float=hard, and
> --with-float=softfp compiler then checking the loader path for all
> combinations of {,-mglibc,-mbionic,-muclibc} x
> {,-mhard-float,-msoft-float,-mfloat-abi=hard,-mfloat-abi=softfp}.
> 
> > (c) Please include libc-ports on future submissions and provide both the
> > GCC patch and the glibc ports patch that have been tested to work together
> > to build and install the library in the given path; a patch to one
> > component like this cannot sensibly be considered in isolation.  I imagine
> > you'll need appropriate ARM preconfigure support to detect what ABI the
> > compiler is using, much like the support for MIPS, so that the right
> > shlib-versions files are used.
> 
> Agreed.
> 
> >  I try to follow all ARM glibc discussions
> > on libc-ports closely, as the ARM glibc maintainer; was there a previous
> > discussion of the dynamic linker naming issue there that I missed?
> 
> Steve McIntyre is driving this inside Debian.  I'll ping him on the
> GLIBC support.
> 
> The tricky one is new GCC with old GLIBC.  GCC may have to do a
> configure time test and fall back to /lib/ld-linux.so.3 if the hard
> float loader is missing.
> 
> >  (The only previous relevant discussion that I recall is one on
> > patches@eglibc.org starting at
> > <http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the
> > dynamic linker should check that a library has the right ABI, and there
> > was no real followup on that after I indicated what would seem to be the
> > appropriate implementation approaches and places for subsequent
> > discussion.)
> 
> The patch above changes the loader to catch a mixed installation and
> reject mixing incompatible libraries.  The static linker does this
> currently but it's not essential.
> 
> > I have no idea whether shlib-versions files naming a file in a
> > subdirectory will work - but if not, you'd need to send a patch to
> > libc-alpha to support dynamic linkers in subdirectories, with appropriate
> > justification for why you are doing something different from all other
> > architectures.
> 
> Understood.  For now this is just a path.  There's more infrastructure
> work needed if the path includes a directory.
> 
> > (d) Existing practice for Power Architecture and MIPS at least is that
> > hard-float and soft-float *don't* use different library directories /
> > dynamic linkers.
> 
> The goal is to have a standard loader path for all hard float distros
> and, similar to how you can have a mixed 32/64 bit installation, allow
> mixed softfp/hard float installations for distros that want it.  This
> is a new requirement and ARM is the first one exposed to it.  I assume
> Debian would push for similar changes on MIPS and PowerPC.
> 
> Do the MIPS or PowerPC loaders detect the ABI and change the library
> path based on that?  I couldn't tell from the code.
> 
> > (e) Existing practice for cases that do use different dynamic linkers is
> > to use a separate library directory, not just dynamic linker name, as in
> > lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
> > make two sets of libraries work in parallel if you have separate library
> > directories like that.
> 
> Is this required, or should it be left to the distro to choose?  Once
> the loader is in control then it can account for any distro specific
> features, which may be the standard /lib and /usr/lib for single ABI
> distros like Fedora or /usr/lib/$tuple for multiarch distros like
> Ubuntu and Debian.
> 
> > So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to
> > handle that directory, I think)
> 
> I'd like to leave that discussion for now.  The Debian goal is to
> support incompatible ABIs and, past that, incompatible architectures.
> libhf is ambiguous as you could have a MIPS hard float library
> installed on the same system as an ARM hard float library.
> 
> > and these different Debian-style names
> > could be implemented separately in a multiarch patch if someone submits
> > one that properly accounts for my review comments on previous patch
> > versions (failure to produce such a fixed patch being why Debian multiarch
> > directory support has not got into GCC so far).
> 
> Agreed.  Note that this loader path discussion is unrelated to
> multiarch.  It came from the same people so there's a family
> resemblance.
> 
> (BTW Dann, apologies for stealing your patch)

 s/stealing/improving upon/  :)

No worries, it is appreciated.

> -- Michael
> 
> 2012-04-03  Michael Hope  <michael.hope@linaro.org>
> 
>        * config/arm/linux-eabi.h (GLIBC_DYNAMIC_LINKER_HARD_FLOAT): Define.
>        (GLIBC_DYNAMIC_LINKER): Redefine to use the hard float path.
> 
> diff --git a/gcc/config/arm/linux-eabi.h b/gcc/config/arm/linux-eabi.h
> index 80bd825..8c9d2e7 100644
> --- a/gcc/config/arm/linux-eabi.h
> +++ b/gcc/config/arm/linux-eabi.h
> @@ -62,7 +62,11 @@
>  /* Use ld-linux.so.3 so that it will be possible to run "classic"
>     GNU/Linux binaries on an EABI system.  */
>  #undef  GLIBC_DYNAMIC_LINKER
> -#define GLIBC_DYNAMIC_LINKER "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "/lib/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER_HARD_FLOAT
> "/lib/arm-linux-gnueabihf/ld-linux.so.3"
> +#define GLIBC_DYNAMIC_LINKER \
> +   "%{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> +    %{!mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}"
> 
>  /* At this point, bpabi.h will have clobbered LINK_SPEC.  We want to
>     use the GNU/Linux version, not the generic BPABI version.  */

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Wed, 4 Apr 2012 07:09:46 -0500
Dennis Gilmore <dennis@gilmore.net.au> wrote:
> Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
> wouldn't object to /libhf  though today we have f17 about to go beta
> and all of rawhide built using /lib 

Hi Dennis,

  One potential problem that is born from the /libhf suggestion is the danger of having a new top level directory (/libhf) with only one file, the dynamic linker. AFAIU it, no distro is currently willing to move away from its existing scheme (/lib), Debian is most likely not going to, at best there could be a symlink /libhf -> /lib/<triplet>, but that is not solving the problem IMHO. What about other distros, if everyone is going to use a symlink for /libhf, then even suggesting it and relying on new top-level directories to solve the problem is the wrong approach. 

Loic suggested a -IMHO- better solution: to change the dynamic linker filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular case).

My 2c.

-- 
Konstantinos Margaritis <konstantinos.margaritis@linaro.org>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Dennis Gilmore]

El Wed, 4 Apr 2012 08:54:12 +0200
Jakub Jelinek <jakub@redhat.com> escribió:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> > >  I did two ports of Mandriva to armv7. One of my choice to use
> > > softfp, and another hardfp port to be compatible with other
> > > distros. But other than a previous armv5 port, there is not much
> > > else of Mandriva arm, so, it would be "good to have" to be able
> > > to run binaries for either without resorting to a chroot, and
> > > only testing purposes.
> > >
> > >  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> > 
> > I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> > questions here though: can the hard float loader have a different
> > path and, if so, what should it be?  We're still working on the
> > first part.
> 
> If the agreement is that arm 32-bit softfp really needs to be
> installable alongside 32-bit hardfp (and alongside aarch64), then
> IMHO it should do it like all other multilib ports (x86_64/i?86/x32,
> s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says,
> e.g. use /lib/ld-linux.so.3 and */lib dirs for softfp,
> /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> MULTILIB_OSDIRNAMES, etc., have it configured in glibc, and for those
> that choose the Debian layout instead, if it is added somehow
> configurable into upstream gcc/glibc of course handle it similarly
> there.  I just wonder why that hasn't been done 10 years ago and only
> needs doing now (of course, aarch64 is going to be new, talking now
> about the 32-bit softfp vs. hardfp).

Fedora at least plans to not support installing hfp and sfp on the same
system, while not completely decided I don't think we will be
supporting running 32 bit arm binaries on 64 bit arm.  there is not
 a legacy support use case that I can think of i.e. existing common
 proprietary software. Though I imagine that we will use /lib64 for
 consistency with existing 64 bit arches.

Dennis

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Niels de Vos]

On 04/05/2012 03:30 PM, Konstantinos Margaritis wrote:
> On Wed, 4 Apr 2012 07:09:46 -0500
> Dennis Gilmore<dennis@gilmore.net.au>  wrote:
>> Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
>> wouldn't object to /libhf  though today we have f17 about to go beta
>> and all of rawhide built using /lib
>
> Hi Dennis,
>
> One potential problem that is born from the /libhf suggestion is the
> danger of having a new top level directory (/libhf) with only one
> file, the dynamic linker. AFAIU it, no distro is currently willing to
> move away from its existing scheme (/lib), Debian is most likely not
> going to, at best there could be a symlink /libhf ->  /lib/<triplet>,
> but that is not solving the problem IMHO. What about other distros,
> if everyone is going to use a symlink for /libhf, then even
> suggesting it and relying on new top-level directories to solve the
> problem is the wrong approach.
>
> Loic suggested a -IMHO- better solution: to change the dynamic linker
> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this
> particular case).

Note that Fedora is a moving target and there already was a mentioning¹ 
of /lib/<triplet> for libraries earlier this year during a developers 
conference². I am not sure what the current status of that proposal is, 
but I think it is entirely possible that Fedora may follow the format 
Debian is using.

Cheers,
Niels


¹ see page 5 from this presentation: 
http://rvokal.fedorapeople.org/devconf2012/harald-A_streamlined_and_fully_compatible_Linux_Files.pdf

² http://fedoraproject.org/wiki/DeveloperConference2012

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Wed, Apr 04, 2012 at 01:11:33AM +0200, Jakub Jelinek wrote:
>On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote:
>> >> The subdirectories could be called fred and jim and it would still work.
>> >>  The only thing required is that this part of the naming scheme be
>> >> agreed amongst the distros.
>> >>
>> >> This looks to me like it's turning into a bike-shed painting excerise
>> >> between the distros out there.  That's really sad.
>> >
>> > I don't think we ever even had the discussion: Debian invented their
>> > Debian-internal scheme for managing multiple ABIs.  They have in the past
>> > used patched versions of gcc, as in the case of x86_64.
>> 
>> (cc'ed cross-distro as the discussion is also going on there[1].  This
>> patch continues that)
>> 
>> I like the idea of incompatible binaries having different loaders.
>> The path doesn't matter but the concept does.  Like i686/x86_64, it
>> gives distros the option to install different binaries alongside each
>> other for compatibility, performance, or upgrade reasons.  The
>> compatibility cost is nice and low and lets Debian do some interesting
>> cross development things.
>
>Does the dynamic linker itself contain any routines that depend on the
>soft/hard ABI?  That would quite surprise me, so I don't see the point of
>having different dynamic linkers for those ABIs.  One dynamic linker should
>handle both just fine.

That's been discussed previously, yes. While technically quite
feasible in terms of code, there's enough potential for confusion that
we though it was just simpler to use two different linker binaries.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>2012/4/4 Paulo César Pereira de Andrade
>>
>>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> and another hardfp port to be compatible with other distros. But other
>> than a previous armv5 port, there is not much else of Mandriva arm,
>> so, it would be "good to have" to be able to run binaries for either
>> without resorting to a chroot, and only testing purposes.
>>
>>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
>
>I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
>questions here though: can the hard float loader have a different path
>and, if so, what should it be?  We're still working on the first part.

We've previously discussed changing the name or the version number of
the linker, but there was a worry that compatibility would be
broken. Apparently the Meego folks have released a hard-float system
using ld-linux.so.3 and were concerned about this.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Tue, Apr 03, 2012 at 10:56:18PM +0000, Joseph S. Myers wrote:
>
>(c) Please include libc-ports on future submissions and provide both the 
>GCC patch and the glibc ports patch that have been tested to work together 
>to build and install the library in the given path; a patch to one 
>component like this cannot sensibly be considered in isolation.  I imagine 
>you'll need appropriate ARM preconfigure support to detect what ABI the 
>compiler is using, much like the support for MIPS, so that the right 
>shlib-versions files are used.  I try to follow all ARM glibc discussions 
>on libc-ports closely, as the ARM glibc maintainer; was there a previous 
>discussion of the dynamic linker naming issue there that I missed?  (The 
>only previous relevant discussion that I recall is one on 
>patches@eglibc.org starting at 
><http://www.eglibc.org/archives/patches/msg01017.html>, regarding how the 
>dynamic linker should check that a library has the right ABI, and there 
>was no real followup on that after I indicated what would seem to be the 
>appropriate implementation approaches and places for subsequent 
>discussion.)

Apologies, that was my fault - I was kept busy on other things and
didn't get back to that. At the time it didn't seem so critical when
we were still experimenting with other aspects of the system. I'll get
back to that shortly...

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
> >2012/4/4 Paulo César Pereira de Andrade
> >
> >>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
> >> and another hardfp port to be compatible with other distros. But other
> >> than a previous armv5 port, there is not much else of Mandriva arm,
> >> so, it would be "good to have" to be able to run binaries for either
> >> without resorting to a chroot, and only testing purposes.
> >> 
> >>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
> >
> >I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
> >questions here though: can the hard float loader have a different path
> >and, if so, what should it be?  We're still working on the first part.
> 
> We've previously discussed changing the name or the version number of
> the linker, but there was a worry that compatibility would be
> broken. Apparently the Meego folks have released a hard-float system
> using ld-linux.so.3 and were concerned about this.

i'm not sure how changing the leading dir components but leaving the base path 
the same would be any more or less work for meego to maintain backwards 
compatibility.  whatever random path is picked, they're going to be broken, as 
the ELF encodes the full path to the ldso.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
> > Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
> > wouldn't object to /libhf  though today we have f17 about to go beta
> > and all of rawhide built using /lib
> 
>   One potential problem that is born from the /libhf suggestion is the
> danger of having a new top level directory (/libhf) with only one file,
> the dynamic linker. AFAIU it, no distro is currently willing to move away
> from its existing scheme (/lib)

i don't think that's true.  on an x86_64 system, the 64bit libs are in 
/lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
imo, and afaik, they didn't break the ldso paths.

so in a setup that only has hardfloat binaries, you'd have all the libs in 
/libhf/, not just the ldso.

> Loic suggested a -IMHO- better solution: to change the dynamic linker
> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> case).

the implication in supporting both hardfloat and softfloat simultaneously is 
that you'd could have them both installed.  thus putting them both in /lib/ 
doesn't make much sense if you're still going to need /libhf/ to hold 
everything else.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Thu, 5 Apr 2012 11:08:56 -0400
Mike Frysinger <vapier@gentoo.org> wrote:
> i don't think that's true.  on an x86_64 system, the 64bit libs are in 
> /lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
> /lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
> imo, and afaik, they didn't break the ldso paths.
> 
> so in a setup that only has hardfloat binaries, you'd have all the libs in 
> /libhf/, not just the ldso.

That's exactly my concern. If /libhf is chosen for the dymamic linker path, but it's not adopted by everyone else for libraries and other files, then at best you'd have a symlink, at worst a dir with only one file inside. 

> the implication in supporting both hardfloat and softfloat simultaneously is 
> that you'd could have them both installed.  thus putting them both in /lib/ 
> doesn't make much sense if you're still going to need /libhf/ to hold 
> everything else.

That case has only any chance of realization in a multiarch environment such as Debian/Ubuntu. The rest won't be affected at all. And the dynamic linkers -different filename of course- are the only libs that will be in /lib straight, the rest will be in /lib/<triplet>. So there is no danger of any conflict, at least not with libraries.

-- 
Konstantinos Margaritis <konstantinos.margaritis@linaro.org>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Paulo César Pereira de Andrade]

Em 5 de abril de 2012 12:09, Mike Frysinger <vapier@gentoo.org> escreveu:
> On Thursday 05 April 2012 10:38:07 Steve McIntyre wrote:
>> On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote:
>> >2012/4/4 Paulo César Pereira de Andrade
>> >
>> >>  I did two ports of Mandriva to armv7. One of my choice to use softfp,
>> >> and another hardfp port to be compatible with other distros. But other
>> >> than a previous armv5 port, there is not much else of Mandriva arm,
>> >> so, it would be "good to have" to be able to run binaries for either
>> >> without resorting to a chroot, and only testing purposes.
>> >>
>> >>  Bumping major or calling it ld-linux-foo.so.3 is out of question?
>> >
>> >I suspect /lib/ld-linux-$foo.so.3 would be fine.  There's two
>> >questions here though: can the hard float loader have a different path
>> >and, if so, what should it be?  We're still working on the first part.
>>
>> We've previously discussed changing the name or the version number of
>> the linker, but there was a worry that compatibility would be
>> broken. Apparently the Meego folks have released a hard-float system
>> using ld-linux.so.3 and were concerned about this.
>
> i'm not sure how changing the leading dir components but leaving the base path
> the same would be any more or less work for meego to maintain backwards
> compatibility.  whatever random path is picked, they're going to be broken, as
> the ELF encodes the full path to the ldso.
> -mike

  I guess now it is too late to defer --with-float=hard for 64 bit armv8, but
besides possibly tedious, full rebuilds of, (hopefully) yet to be released
hardfp distros per se is not a bad thing.

  My suggestion for lib$color is $color == vfp (one could choose neon :-),
and then it is a distro choice if using /lib as software float to be able to
install the same binaries on armv4+, or build with vfp but use software float
abi so that armv4+ binaries work.

  Major issue IMO is that things are being done thinking too much on
the now, so, hardfp is good to support nvidia drivers, and plain soft float
(armv5) is good for raspberry pi...

> _______________________________________________
> cross-distro mailing list
> cross-distro@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Paulo

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Thursday 05 April 2012 11:24:15 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger wrote:
> > i don't think that's true.  on an x86_64 system, the 64bit libs are in
> > /lib64/.  some distros tried to (pointlessly imo) resist and force 64bits
> > into /lib/ when the native ABI was x86_64 (Gentoo included), but those
> > are legacy imo, and afaik, they didn't break the ldso paths.
> > 
> > so in a setup that only has hardfloat binaries, you'd have all the libs
> > in /libhf/, not just the ldso.
> 
> That's exactly my concern. If /libhf is chosen for the dymamic linker path,
> but it's not adopted by everyone else for libraries and other files, then
> at best you'd have a symlink, at worst a dir with only one file inside.

if gcc declares libhf as another multilib target, then everyone else will get 
it automatically

note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or 
/libhf/ld-linux.so.[34].  /lib/<triplet>/<ldso> is really the only one i don't 
think doesn't belong.

> > the implication in supporting both hardfloat and softfloat simultaneously
> > is that you'd could have them both installed.  thus putting them both in
> > /lib/ doesn't make much sense if you're still going to need /libhf/ to
> > hold everything else.
> 
> That case has only any chance of realization in a multiarch environment
> such as Debian/Ubuntu.

don't really know what you're talking about here.  other distros have no 
problem with handling multilib.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 11:32:39AM +1200, Michael Hope wrote:
>
>So:
> * Big endian: undefined, defaults to /lib/ld-linux.so.3
> * Little endian, soft float: /lib/ld-linux.so.3
> * Little endian, hard float: /libhf/ld-linux.so.3
>
>> Standard upstream practice supports having multiple variants that
>> plausibly run on the same system at the same time, such as /lib and
>> /lib64, and it seems reasonable to support hard and soft float variants
>> that way via a directory such as /libhf.  The Debian-style paths are not
>> the default on any other architecture and I don't think it's appropriate
>> to make them the default for this particular case only.
>
>OK.  Debian multiarch covers libraries and headers but not
>executables.  As a MIPS hard float /usr/bin/ls would collide with an
>ARM hard float /usr/bin/ls then it's fine for the loader names to
>potentially collide as well.
>
>In practice they wouldn't as most architecture has a subtily different
>loader name (cf. ld.so.1 for MIPS, ld-linux.so.2 for i386, and
>ld-linux.so.3 for ARM).

Yes, thankfully. More by luck than any design.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 01:16:27PM +1200, Michael Hope wrote:
>On 5 April 2012 12:07, Joseph S. Myers <joseph@codesourcery.com> wrote:
>>
>> No.  A system is either purely hard-float or purely soft-float, and the
>> same paths are used for both so they can't coexist.  (Mismatches at
>> *static* link time are detected through object attributes.)
>
>Ah, the same as ARM then.  The MIPS community would need something
>similar to this patch if they wanted to support soft and hard float
>side by side.

Yes, definitely.

>>> Big endian is extremely uncommon on ARM and I'd rather define it when
>>> needed.  For strictness sake I'll change the patch to use the new path
>>> for hard float little endian only.
>>
>> I don't think that's correct; the new path should be used independent of
>> endian, just as the existing path is.
>
>OK.
>
>> But any multiarch support patch
>> should presumably define separate multiarch paths for each endianness.
>
>That's up to Debian.  I've asked for documentation on the final tuples
>and what they mean as the one at:
> http://wiki.debian.org/Multiarch/Tuples
>
>is out of date.  I prefer defining what is needed now and doing others
>as needed.

I'm most of the way through an update for that page now; I'll ask for
comments/review shortly.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
>On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
>> On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore wrote:
>> > Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but
>> > wouldn't object to /libhf  though today we have f17 about to go beta
>> > and all of rawhide built using /lib
>> 
>>   One potential problem that is born from the /libhf suggestion is the
>> danger of having a new top level directory (/libhf) with only one file,
>> the dynamic linker. AFAIU it, no distro is currently willing to move away
>> from its existing scheme (/lib)
>
>i don't think that's true.  on an x86_64 system, the 64bit libs are in 
>/lib64/.  some distros tried to (pointlessly imo) resist and force 64bits into 
>/lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy 
>imo, and afaik, they didn't break the ldso paths.
>
>so in a setup that only has hardfloat binaries, you'd have all the libs in 
>/libhf/, not just the ldso.
>
>> Loic suggested a -IMHO- better solution: to change the dynamic linker
>> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
>> case).
>
>the implication in supporting both hardfloat and softfloat simultaneously is 
>that you'd could have them both installed.  thus putting them both in /lib/ 
>doesn't make much sense if you're still going to need /libhf/ to hold 
>everything else.

Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
them all in cleanly-separated paths corresponding to the triplets.

I'm concerned that the potential proliferation of /lib* directories
here could become very messy over time. I'm surprised that people seem
to be happy to invent another namespace on a much more ad-hoc and
arbitrary basis than the (mostly) well-understood triplets that we
already have defined in the toolchains.

Multi-arch is an attempt to make things cleaner for those of us that
care about having lots of different platforms supported in
parallel. Seen against that background, I was hoping that using the
multi-arch path for the armhf linker would make sense. For people that
don't care about multi-arch for themselves, a simple symbolic link is
all that's needed.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Thu, 5 Apr 2012 11:55:14 -0400
Mike Frysinger <vapier@gentoo.org> wrote: 
> note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or 
> /libhf/ld-linux.so.[34].  /lib/<triplet>/<ldso> is really the only one i don't 
> think doesn't belong.

and I'm just saying that I dislike /libhf, I also think that just raising the version is a wrong solution.

> don't really know what you're talking about here.  other distros have no 
> problem with handling multilib.

multilib for softfloat/hardfloat on arm? I don't think so, even for other arches -it was already demonstrated that you cannot e.g. have powerpc e500v2 and e600 installed concurrently, and anyway that's not the topic of the discussion here. Apart from multiarch there is no other solution to do that *for* arm, at least at the moment, because the two ABIs use exactly the same paths on a non-multiarch system. And I get back to the proposed solution /libhf -which is the multilib path you're referring to- and I'm saying that the topic here is for the linker path alone. In the hypothetical scenario that everyone agreed on /libhf for the linker path, but not for libraries -which would stay in /lib- , then we'd have a /libhf top directory with just one file, the linker. Or a symlink from /lib to /libhf or /lib/<triplet> to /libhf in Debian's case, but that defeats the purposes of having a new /libhf directory, doesn't it?

I hope I was clearer now.

-- 
Konstantinos Margaritis <konstantinos.margaritis@linaro.org>

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:
> On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:
> >On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:
> >> Loic suggested a -IMHO- better solution: to change the dynamic linker
> >> filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular
> >> case).
> >
> >the implication in supporting both hardfloat and softfloat simultaneously
> >is that you'd could have them both installed.  thus putting them both in
> >/lib/ doesn't make much sense if you're still going to need /libhf/ to
> >hold everything else.
> 
> Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put
> them all in cleanly-separated paths corresponding to the triplets.

/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/).  
i see no difference here with a gcc configured for these multilib paths.

> I'm concerned that the potential proliferation of /lib* directories
> here could become very messy over time. I'm surprised that people seem
> to be happy to invent another namespace on a much more ad-hoc and
> arbitrary basis than the (mostly) well-understood triplets that we
> already have defined in the toolchains.

the triplet situation isn't as clean as you imply here.  there are already 
examples of not being able to tell the ABI based purely on that.  mips64-
linux-gnu could be n32 or n64.  x86_64-linux-gnu could be x86_64 or x32.

the Debian multiarch project might have made up new triplets to account for 
this, but those don't translate exactly into the same triplet that are used 
for e.g. configure --host.

> Multi-arch is an attempt to make things cleaner for those of us that
> care about having lots of different platforms supported in
> parallel. Seen against that background, I was hoping that using the
> multi-arch path for the armhf linker would make sense.

if you think that's a useful goal, then sure.  but not everyone thinks the 
multiarch proposal is really all that useful.  however, that (much larger) 
discussion is really out of scope here.

> For people that don't care about multi-arch for themselves, a simple
> symbolic link is all that's needed.

i think it's safe to say that the wider community has yet to be convinced, so 
extending existing support via the existing standards makes more sense.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Adam Conrad]

On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
> On 4 April 2012 18:54, Jakub Jelinek <jakub@redhat.com> wrote:
> >
> > If the agreement is that arm 32-bit softfp really needs to be installable
> > alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
> > like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
> > various MIPS variants) and what FSB says, e.g. use
> > /lib/ld-linux.so.3 and */lib dirs for softfp,
> > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> > MULTILIB_OSDIRNAMES, etc., have it configured in glibc
> 
> OK.  This gives a different path for the hard float loader and lets
> the Debian guys add on top of that.  I'll ping them and see what they
> think.

The problem here that everyone !Debian isn't taking into account is that
multilib paths don't solve our use-case.  Multilib paths only solve the
case of multiple ABIs on the same base processor family.  As soon as you
combine x86, arm, power, etc, you end up with overlaps (or, the potential
for overlaps; the fact that various arches accidentally have different
majors keeps those overlaps to a minimum right now, but that's not by
design).

Honestly, this is something we should have solved two decades ago, but the
very idea that someone would want to do what Debian is now doing didn't
occur to any of us.  That's cool.  We didn't think of it back then.  That's
no excuse to continue with the status quo just because it's the status quo.

To be perfectly clear here, we don't care where the linker goes (really, we
don't), we just want it to be both arch and ABI unique.  If that means
taking a crc32 of a rot-13 of the compiler flags used to define the ABI,
and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it.

If this means setting up a (very) lightweight process with the LSB, where
everytime a new distro proposes a shiny new arch/ABI, they submit it, and
the LSB assigns them an ABI serial, and we all then agree to toss the
linker in /lib/abi-00002345/ld-linux, that works too.  Don't care.  Really
don't care.

This isn't about trying to force people to switch from multilib to multi-
arch, where the former is clearly working fine for them.  It's not.  This
is purely about people bikeshedding about paths they consider un-pretty,
while (I hope not maliciously or knowingly?) causing potential overlap and
breakage for those of us for whom this actually matters and isn't purely
a color selection exercise.

In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for
us, purely because that doesn't overlap with any other linkers that Debian
currently ships.  The fact that the multilib path happens to work doesn't
make it correct for our use-case, and certainly doesn't make it correct
ongoing.

Ultimately, however, I want this solved.  We thought we had this solved at
Plumbers last fall.  To hear now that we "didn't involve everyone" is
disheartening, given that we ("we" being Debian and Ubuntu) were well
outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
Gentoo.  We all agreed on something back then, and now that I'm three
weeks away from shipping an armhf distro, it's all exploded yet again into
Bikeshed Part III: The Revenge of Purple Paint.

I really want to ship a compiler than stuffs the "correct" and agreed
upon linker in headers.  I don't want to see third parties build binaries
on Ubuntu that don't run on Fedora.  No one wants to see that, I think.

Obviously, conversely (though this is much less hassle), I need to be
able to ship a linker symlink that matches expectations, so that binaries
built on Fedora will run on Ubuntu.  Again, I'm sure we all want that.

So, pretty please, can we (A) address the concerns here without people
putting up the "Unique paths are Debian trying to force multi-arch on us"
straw man, and (B) agree to *something*, before I ship something that
conforms to a standard agreed upon more than half a year ago that is now
a cause for contention?  Pretty please?  With sugar on top?  Kthx.

> > (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
> 
> Yip.  I assume something like /lib64 to stay consistent with other
> architectures.  aarch64 is hard float only.

I expect that most distros will probably ship their aarch64 libraries
in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent
with their other 64-bit ports, but where you put libraries is entirely
unrelated to where the linker lives.  You could have all your libraries
in /root/.trash/ and if the linker lives in a canonical location and
can resolve that, that's fine.  I will still (obviously, I think, from
my comments above) argue that the linker should live in a guaranteed
unique location.  Overlap with other arches in /lib64 is certainly far
more likely than overlap in /libhf.

... Adam Conrad

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Monday 09 April 2012 16:48:06 Adam Conrad wrote:
> On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
> > On 4 April 2012 18:54, Jakub Jelinek wrote:
> > > If the agreement is that arm 32-bit softfp really needs to be
> > > installable alongside 32-bit hardfp (and alongside aarch64), then IMHO
> > > it should do it like all other multilib ports (x86_64/i?86/x32,
> > > s390/s390x, ppc/ppc64, the various MIPS variants) and what FSB says,
> > > e.g. use
> > > /lib/ld-linux.so.3 and */lib dirs for softfp,
> > > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
> > > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
> > > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
> > > MULTILIB_OSDIRNAMES, etc., have it configured in glibc
> > 
> > OK.  This gives a different path for the hard float loader and lets
> > the Debian guys add on top of that.  I'll ping them and see what they
> > think.
> 
> The problem here that everyone !Debian isn't taking into account is that
> multilib paths don't solve our use-case.  Multilib paths only solve the
> case of multiple ABIs on the same base processor family.  As soon as you
> combine x86, arm, power, etc, you end up with overlaps

and the problem there is that you're assuming anyone !Debian sees this as a 
problem.  so, once again, do not use the armhf standardization work to 
backdoor multiarch.  if you want to talk about multiarch, then start a new 
thread to do that.

> Ultimately, however, I want this solved.  We thought we had this solved at
> Plumbers last fall.  To hear now that we "didn't involve everyone" is
> disheartening, given that we ("we" being Debian and Ubuntu) were well
> outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
> Gentoo.

tbh, i thought the ldso discussion was more "we've been talking about this for 
a long time, so let's just go with XXX" and then people moved on to the next 
topic (which was defining exactly what "hard float abi" meant wrt compiler 
flags).  further, it seemed like we had distro representation there, but not 
mainline gcc people.

> So, pretty please, can we (A) address the concerns here without people
> putting up the "Unique paths are Debian trying to force multi-arch on us"
> straw man, and (B) agree to *something*, before I ship something that
> conforms to a standard agreed upon more than half a year ago that is now
> a cause for contention?  Pretty please?  With sugar on top?  Kthx.

again, saying "/lib/<tuple>/<ldso>" isn't multiarch is bunk.  but it sounds 
like you're fine with /libhf/, so there isn't anything left to thrash about 
there.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Adam Conrad]

On Mon, Apr 09, 2012 at 07:14:45PM -0400, Mike Frysinger wrote:
> 
> again, saying "/lib/<tuple>/<ldso>" isn't multiarch is bunk.  but it sounds 
> like you're fine with /libhf/, so there isn't anything left to thrash about 
> there.

I appreciate your careful reading of my email and the issues I outlined,
and I look forward to your new urbandictionary definition of the common
colloquialism "fine with".

A path for one file isn't multi-arch.  A unique path for linkers does help
facilitate multi-arch, but we're not forcing you to put libraries some
place you don't want to, implement new ideas you don't want to, or any
other such "bunk", as you so obviously impartially put it.

I realize that most people can't see past their own use case to understand
why a unique location for linkers is helpful, useful, and important for
some other people's use cases, but you either didn't read or chose to
ignore why using multilib paths just plain doesn't scale past a single
base architecture, and why that's a problem for people who aren't you.

This isn't about pushing multi-arch on others.  This isn't about pushing
multi-arch on others.  Also, this.  Isn't.  About.  Pushing.  Multi-arch.
On.  Others.  I don't know how much more clear I can make that.

If the QT guys filed a bug/feature request on libstdc++ asking to change
something that didn't break C++ standards, but facilitated some fancy
thing they were working on, my response wouldn't be "dude, I use GTK,
what do I care about your weird needs, screw you and your QT agenda", it
would be to ask them why they need the thing they need, evaluate how, if
in any way, that would impact other users, and work with them.

Using unique linker paths (for new architectures) hurts exactly zero
users, and this discussion has taken up FAR MORE developer time than
implementation ever would have.  Arguing against unique linker paths for
the reason that "we've never done that before" is not helpful, and it's
blatantly ignoring technical arguments and hiding them behind some bizarre
inter-distro conspiracy theory.

Maybe the conspiracy theory is fun for you.  I don't know.  It's not for
me.  We were told by GCC upstream that we needed distro consensus.  We
got that over half a year ago.  Now I'm told by distros that the patch
not being upstream is why they are backing out of said consensus.  Fun.

.... Adam Conrad

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> I realize that most people can't see past their own use case to understand
> why a unique location for linkers is helpful, useful, and important for
> some other people's use cases, but you either didn't read or chose to
> ignore why using multilib paths just plain doesn't scale past a single
> base architecture, and why that's a problem for people who aren't you.

and as already stated, the proposed paths here, free of multiarch subpaths, 
satisfy the requirements that you've put forth
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Thursday 05 April 2012 12:25:09 Konstantinos Margaritis wrote:
> On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger wrote:
> > note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or
> > /libhf/ld-linux.so.[34].  /lib/<triplet>/<ldso> is really the only one i
> > don't think doesn't belong.
> 
> and I'm just saying that I dislike /libhf, I also think that just raising
> the version is a wrong solution.

i can see why bumping ver # is undesirable, but i don't think it's that big of 
a deal.  the ldso is a bit of a magic beast, so i don't think applying the 
same SONAME versioning rules is terribly important.  especially since ARM has 
already moved from ld-linux.so.2 for OABI to ld-linux.so.3 for EABI.  you 
could even argue that enshrining hardfloat is actually an ABI version bump, so 
ld-linux.so.4 is appropriate.  and really, once you bump the SONAME, injecting 
substrings like "hf" are no different.

> > don't really know what you're talking about here.  other distros have no
> > problem with handling multilib.
> 
> multilib for softfloat/hardfloat on arm? I don't think so, even for other
> arches -it was already demonstrated that you cannot e.g. have powerpc
> e500v2 and e600 installed concurrently,

i'm not familiar with ppc's embedded variants, so i can't speak to these 
examples

> and anyway that's not the topic of
> the discussion here. Apart from multiarch there is no other solution to do
> that *for* arm, at least at the moment, because the two ABIs use exactly
> the same paths on a non-multiarch system.

i'm not sure why you think that.  if people actually want to do multilib with 
these, then there's nothing stopping people from doing that, once the ldso's 
are in a unique path.

> And I get back to the proposed
> solution /libhf -which is the multilib path you're referring to- and I'm
> saying that the topic here is for the linker path alone. In the
> hypothetical scenario that everyone agreed on /libhf for the linker path,
> but not for libraries -which would stay in /lib- , then we'd have a /libhf
> top directory with just one file, the linker. Or a symlink from /lib to
> /libhf or /lib/<triplet> to /libhf in Debian's case, but that defeats the
> purposes of having a new /libhf directory, doesn't it?

what Debian chooses to do with multiarch is up to Debian ... i don't think it 
should have any bearing here.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jeff Law]

On 04/09/2012 05:14 PM, Mike Frysinger wrote:
>
> tbh, i thought the ldso discussion was more "we've been talking about this for
> a long time, so let's just go with XXX" and then people moved on to the next
> topic (which was defining exactly what "hard float abi" meant wrt compiler
> flags).  further, it seemed like we had distro representation there, but not
> mainline gcc people.
Actually Mike, there was at least one mainline GCC person there.  Me. 
Of course I was thrown into a discussion I knew nothing about, but the 
goal of having a standardized path to discover ld.so which worked across 
distros seems like goodness to me.  Honestly, I don't see what all the 
resistance is about.

Jeff

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Tuesday 10 April 2012 00:16:34 Jeff Law wrote:
> On 04/09/2012 05:14 PM, Mike Frysinger wrote:
> > tbh, i thought the ldso discussion was more "we've been talking about
> > this for a long time, so let's just go with XXX" and then people moved
> > on to the next topic (which was defining exactly what "hard float abi"
> > meant wrt compiler flags).  further, it seemed like we had distro
> > representation there, but not mainline gcc people.
> 
> Actually Mike, there was at least one mainline GCC person there.  Me.

my mistake.  i don't think we've met before, and that was a fairly busy time 
for me, so i probably missed things.  we should get a beer ;).

> Of course I was thrown into a discussion I knew nothing about

admittedly, that was the first time i've been in a linaro-related meeting 
before, and i hadn't been following linaro at all before (as the job i left 
before wasn't working on arm at all)

> goal of having a standardized path to discover ld.so which worked across
> distros seems like goodness to me.  Honestly, I don't see what all the
> resistance is about.

i think we have suggestions that would work for everyone ... but maybe this 
thread has gotten too big so we need to regroup with a summary
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Adam Conrad]

On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
> On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> > I realize that most people can't see past their own use case to understand
> > why a unique location for linkers is helpful, useful, and important for
> > some other people's use cases, but you either didn't read or chose to
> > ignore why using multilib paths just plain doesn't scale past a single
> > base architecture, and why that's a problem for people who aren't you.
> 
> and as already stated, the proposed paths here, free of multiarch subpaths, 
> satisfy the requirements that you've put forth

Like I said, then, you didn't actually read or understand why proposing
multilib paths doesn't work.  You realize conceptually, I hope, that
there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
you cross the base CPU architecture boundary, right?

Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for
us right now, due to sheer luck, and you're running with that as saying
that we clearly have no problem here worth solving.  When the next
architecture clashes with linkers on another (hint: it almost certainly
will), do we get to argue about this all over again in six months,
instead of codifying a new and saner practice now?

... Adam Conrad

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Paulo César Pereira de Andrade]

Em 9 de abril de 2012 17:48, Adam Conrad <adconrad@debian.org> escreveu:
> On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
>> On 4 April 2012 18:54, Jakub Jelinek <jakub@redhat.com> wrote:
>> >
>> > If the agreement is that arm 32-bit softfp really needs to be installable
>> > alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
>> > like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
>> > various MIPS variants) and what FSB says, e.g. use
>> > /lib/ld-linux.so.3 and */lib dirs for softfp,
>> > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
>> > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
>> > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
>> > MULTILIB_OSDIRNAMES, etc., have it configured in glibc
>>
>> OK.  This gives a different path for the hard float loader and lets
>> the Debian guys add on top of that.  I'll ping them and see what they
>> think.
>
> The problem here that everyone !Debian isn't taking into account is that
> multilib paths don't solve our use-case.  Multilib paths only solve the
> case of multiple ABIs on the same base processor family.  As soon as you
> combine x86, arm, power, etc, you end up with overlaps (or, the potential
> for overlaps; the fact that various arches accidentally have different
> majors keeps those overlaps to a minimum right now, but that's not by
> design).
>
> Honestly, this is something we should have solved two decades ago, but the
> very idea that someone would want to do what Debian is now doing didn't
> occur to any of us.  That's cool.  We didn't think of it back then.  That's
> no excuse to continue with the status quo just because it's the status quo.
>
> To be perfectly clear here, we don't care where the linker goes (really, we
> don't), we just want it to be both arch and ABI unique.  If that means
> taking a crc32 of a rot-13 of the compiler flags used to define the ABI,
> and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it.
>
> If this means setting up a (very) lightweight process with the LSB, where
> everytime a new distro proposes a shiny new arch/ABI, they submit it, and
> the LSB assigns them an ABI serial, and we all then agree to toss the
> linker in /lib/abi-00002345/ld-linux, that works too.  Don't care.  Really
> don't care.
>
> This isn't about trying to force people to switch from multilib to multi-
> arch, where the former is clearly working fine for them.  It's not.  This
> is purely about people bikeshedding about paths they consider un-pretty,
> while (I hope not maliciously or knowingly?) causing potential overlap and
> breakage for those of us for whom this actually matters and isn't purely
> a color selection exercise.
>
> In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for
> us, purely because that doesn't overlap with any other linkers that Debian
> currently ships.  The fact that the multilib path happens to work doesn't
> make it correct for our use-case, and certainly doesn't make it correct
> ongoing.
>
> Ultimately, however, I want this solved.  We thought we had this solved at
> Plumbers last fall.  To hear now that we "didn't involve everyone" is
> disheartening, given that we ("we" being Debian and Ubuntu) were well
> outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
> Gentoo.  We all agreed on something back then, and now that I'm three
> weeks away from shipping an armhf distro, it's all exploded yet again into
> Bikeshed Part III: The Revenge of Purple Paint.
>
> I really want to ship a compiler than stuffs the "correct" and agreed
> upon linker in headers.  I don't want to see third parties build binaries
> on Ubuntu that don't run on Fedora.  No one wants to see that, I think.
>
> Obviously, conversely (though this is much less hassle), I need to be
> able to ship a linker symlink that matches expectations, so that binaries
> built on Fedora will run on Ubuntu.  Again, I'm sure we all want that.
>
> So, pretty please, can we (A) address the concerns here without people
> putting up the "Unique paths are Debian trying to force multi-arch on us"
> straw man, and (B) agree to *something*, before I ship something that
> conforms to a standard agreed upon more than half a year ago that is now
> a cause for contention?  Pretty please?  With sugar on top?  Kthx.
>
>> > (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
>>
>> Yip.  I assume something like /lib64 to stay consistent with other
>> architectures.  aarch64 is hard float only.
>
> I expect that most distros will probably ship their aarch64 libraries
> in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent
> with their other 64-bit ports, but where you put libraries is entirely
> unrelated to where the linker lives.  You could have all your libraries
> in /root/.trash/ and if the linker lives in a canonical location and
> can resolve that, that's fine.  I will still (obviously, I think, from
> my comments above) argue that the linker should live in a guaranteed
> unique location.  Overlap with other arches in /lib64 is certainly far
> more likely than overlap in /libhf.

  Not trying to criticize, just attempt to show my view of the subject.
What I understand of Debian multiarch is the desire to be able to:
1. Mount the root directory from a file server in different computers.
  1.1. Computers share user home directories, can see binaries of
       other architectures, and can share "noarch" files, as that would
       be a bug if such files were wordsize or byte order dependent.
2. Boot different kernels (linux, freebsd, etc) and be able to have
   things just working. One kernel may even run binaries targeted
   to the other as they are the same architecture, a U*X is a U*X,
   or close enough.

  Last time I looked at Debian wiki, there was not yet a defined
plan for bin/x-y-z/ paths, so, I understand this is an "incremental"
work in progress, and first goal is to install close enough binaries
together, e.g. run a X Server and drivers built for one ABI and client
applications built for another. Having firefox for one abi, and all
of gtk, and a myriad of loadable modules for another can be painful
to maintain... Applications that link to different ABI libGL looks like
a possible common case. Talking about lib*GL, I believe this is
one of the main reasons of hardfp arm, and only when passing
lots of float/double by value from different DSOs. Other reason is
that newer arm C compiler will support only software float or
hardware float with hardfp abi, but enough about it :-)

  For the sake of a example, TeXLive ships mostly "noarch" files,
and pre built, statically linked binaries are installed in bin/dir with
"dir" being one of:

alpha-linux
amd64-freebsd
amd64-kfreebsd
i386-cygwin
i386-freebsd
i386-kfreebsd
i386-linux
i386-netbsd
i386-solaris
mips-irix
powerpc-aix
powerpc-linux
sparc-linux
sparc-solaris
universal-darwin
win32
x86_64-darwin
x86_64-linux
x86_64-solaris

> ... Adam Conrad
>
>
> _______________________________________________
> cross-distro mailing list
> cross-distro@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro

Thanks,
Paulo

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jakub Jelinek]

On Tue, Apr 10, 2012 at 05:17:36AM +0000, Adam Conrad wrote:
> On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
> > On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> > > I realize that most people can't see past their own use case to understand
> > > why a unique location for linkers is helpful, useful, and important for
> > > some other people's use cases, but you either didn't read or chose to
> > > ignore why using multilib paths just plain doesn't scale past a single
> > > base architecture, and why that's a problem for people who aren't you.
> > 
> > and as already stated, the proposed paths here, free of multiarch subpaths, 
> > satisfy the requirements that you've put forth
> 
> Like I said, then, you didn't actually read or understand why proposing
> multilib paths doesn't work.  You realize conceptually, I hope, that
> there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
> you cross the base CPU architecture boundary, right?

But you are incorrectly assuming that anyone outside Debian actually sees
that as a problem.  When we've designed multilib for Linux (following Irix
layout, which for some weird reason Debian was the only one which ignored
it), it hasn't been a goal and I don't see why it should be a goal now.
For crossing base CPU architecture boundaries we have for many years
--sysroot, you can't run natively the binaries/libraries anyway, while
for ABIs that you can run natively it is very common to run binaries for the
different native ABIs concurrently.

We really want consistency about the dynamic linker names etc. across
different targets and sneaking silently multiarch paths on one architecture
would make it inconsistent with all the others.  So, please just use
/libhf/ld-linux.so.3.

> will), do we get to argue about this all over again in six months,
> instead of codifying a new and saner practice now?

Not everybody agrees it is a saner practice.

	Jakub

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jeff Law]

On 04/09/2012 11:17 PM, Adam Conrad wrote:
>
> Like I said, then, you didn't actually read or understand why proposing
> multilib paths doesn't work.  You realize conceptually, I hope, that
> there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
> you cross the base CPU architecture boundary, right?
But what you haven't done is make a case for why anyone should care 
about this problem.

>
> Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for
> us right now, due to sheer luck, and you're running with that as saying
> that we clearly have no problem here worth solving.  When the next
> architecture clashes with linkers on another (hint: it almost certainly
> will), do we get to argue about this all over again in six months,
> instead of codifying a new and saner practice now?
My understanding of that architecture is that it's being handled as 
completely different from it's prior implementations.  ie, the toolchain 
and other things are treating it as an entirely separate architecture 
even though there is some common lineage to prior implementations.

If the tools are treating this upcoming architecture as a separate and 
distinct architecture rather than as a variant of a prior architecture, 
then why do we have to worry about conflicting in the filesystem space?

And just to be clear, I'm not taking sides, merely pointing out that you 
haven't made the case in this forum in a way that folks understand why 
this is an important problem.

Jeff

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Tue, 10 Apr 2012 07:36:07 +0200
Jakub Jelinek <jakub@redhat.com> wrote:
> We really want consistency about the dynamic linker names etc. across
> different targets and sneaking silently multiarch paths on one architecture
> would make it inconsistent with all the others.  So, please just use
> /libhf/ld-linux.so.3.

I personally find /libhf extremely ugly. If having a second path is a problem, how about using the triplet in the filename? Like:

/lib/ld-linux-arm-linux-gnueabihf.so.3

?

Unique per arch and not multiarched. And AFAIK, Linux can handle long filenames just fine...

Konstantinos

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Dennis Gilmore]

On Tue, 10 Apr 2012 12:18:51 +0300
Konstantinos Margaritis <konstantinos.margaritis@linaro.org> wrote:

> On Tue, 10 Apr 2012 07:36:07 +0200
> Jakub Jelinek <jakub@redhat.com> wrote:
> > We really want consistency about the dynamic linker names etc.
> > across different targets and sneaking silently multiarch paths on
> > one architecture would make it inconsistent with all the others.
> > So, please just use /libhf/ld-linux.so.3.
> 
> I personally find /libhf extremely ugly. If having a second path is a
> problem, how about using the triplet in the filename? Like:
> 
> /lib/ld-linux-arm-linux-gnueabihf.so.3
> 
> ?
> 
> Unique per arch and not multiarched. And AFAIK, Linux can handle long
> filenames just fine...

every distro uses a unique triplet, by putting the triplet in there you
then need to get all distros to change to using the same triplets. I
personally prefer /libhfp rather than /libhf but I am ok with using
either. Any change from /lib  would need us to do a mass rebuild.
because while not 100% needed I would rather keep libraries with the
linker. the changes to rpm to support it would be somewhat minimal. we
have stated in Fedora though that we have no intention to support mixing
hfp and sfp on the same system.  we really do need to ensure consensus
for arm64 which I think should be /lib64 for 64 bit arch consistency.


Dennis

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Konstantinos Margaritis]

On Tue, 10 Apr 2012 09:32:22 -0500
Dennis Gilmore <dennis@gilmore.net.au> wrote: 
> every distro uses a unique triplet, by putting the triplet in there you
> then need to get all distros to change to using the same triplets. I
> personally prefer /libhfp rather than /libhf but I am ok with using
> either. Any change from /lib  would need us to do a mass rebuild.
> because while not 100% needed I would rather keep libraries with the
> linker. the changes to rpm to support it would be somewhat minimal. we
> have stated in Fedora though that we have no intention to support mixing
> hfp and sfp on the same system.  we really do need to ensure consensus
> for arm64 which I think should be /lib64 for 64 bit arch consistency.

Ok, I respect that, what about using the actual ABI name, ie aapcs-vfp? or something that includes both the architecture and the eabi, (arm-hardfloat, armhf, armhfp, etc), but *in* the filename (excluding the case of using a separate directory as it's not too popular).

Also, I'm not suggesting changing the triplet or anything, just deciding on a unique name for the triplet. Debian's argument is that the default multilib solution is not future-proof and we would prefer something that is more unique. 

Regarding /lib64 for aarch64, that's an entirely different discussion, though I do agree it should be also be resolved sooner rather than later as well.

Regards

Konstantinos

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Steve McIntyre]

On Tue, Apr 10, 2012 at 09:32:22AM -0500, Dennis Gilmore wrote:
>On Tue, 10 Apr 2012 12:18:51 +0300
>Konstantinos Margaritis <konstantinos.margaritis@linaro.org> wrote:
>
>> On Tue, 10 Apr 2012 07:36:07 +0200
>> Jakub Jelinek <jakub@redhat.com> wrote:
>> > We really want consistency about the dynamic linker names etc.
>> > across different targets and sneaking silently multiarch paths on
>> > one architecture would make it inconsistent with all the others.
>> > So, please just use /libhf/ld-linux.so.3.
>> 
>> I personally find /libhf extremely ugly. If having a second path is a
>> problem, how about using the triplet in the filename? Like:
>> 
>> /lib/ld-linux-arm-linux-gnueabihf.so.3
>> 
>> ?
>> 
>> Unique per arch and not multiarched. And AFAIK, Linux can handle long
>> filenames just fine...
>
>every distro uses a unique triplet, by putting the triplet in there you
>then need to get all distros to change to using the same triplets.

Aargh. Again, use of a standard triplet for arm hard-float was agreed
by all parties at the Plumbers' meeting last September. For exactly
this reason. Now it seems that a number of people have totally ignored
that consensus for the last six months.

>I personally prefer /libhfp rather than /libhf but I am ok with using
>either. Any change from /lib would need us to do a mass
>rebuild. because while not 100% needed I would rather keep libraries
>with the linker. the changes to rpm to support it would be somewhat
>minimal. we have stated in Fedora though that we have no intention to
>support mixing hfp and sfp on the same system.  we really do need to
>ensure consensus for arm64 which I think should be /lib64 for 64 bit
>arch consistency.

Precisely who in Redhat/Fedora land has the power to make decisions in
this area? We've been clearly wasting our time thus far trying to
negotiate agreements about the hard-float platform.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael Edwards]

FWIW, my use case for multiarch is not "sharing the root filesystem 
among multiple systems".  It's "sharing the non-lib namespace (/etc, 
/bin, data) among multiple instruction sets / ABI variants on the same 
system".  I don't need (/usr)?/s?bin to be decorated with a triplet, 
because the kernel picks a fresh ld.so variant at the execve() boundary; 
I am happy to mix ARM and x86 binaries (and Python and shell scripts) in 
/bin, and let the kernel (and binfmt_misc + qemu) sort it out.  I only 
need (/usr)?/lib to be disambiguated *at runtime* because ld.so is not 
as smart as the kernel.  (It's not just ld.so, of course; module/plugin 
loaders for everything from Python to Firefox have the same problem, and 
if they don't have the triplet in there somewhere then multiarch breaks 
them.)

As long as the kernel can find the right ld.so and each ld.so can find 
its own ld.so.conf, I don't really care where the libraries are put at 
runtime, as long as I can make it different for each ISA/ABI.  However, 
I do care how much autoconf / pkg-config / debhelper misery I have to go 
through each time I need to pull in another library dependency.  
Upstream build machinery can usually accommodate 
/just/about/anything/lib.  Trailing components like lib32, libhf, or 
lib-gnu-autoconf-triplet are not as consistently trivial.

Personally, I would like for all shared objects to live in 
(/usr)?/gnu-autoconf-triplet(-extranoise)?/lib, and for the kernel to 
take responsibility for pointing (/usr)?/lib at an overlay mount 
containing whatever makes sense for the currently running binary, a la 
/proc/self.  That way I can grandfather in binaries with ABI-ignorant 
hard-coded library paths, and still handle ISA variants.  The 
"extranoise" might be "neon", or "ssse3", or "android" (so that 
non-Android binaries on the same system don't see Android-specific 
libraries with stupidly generic names like libui.so).  And the overlay 
mount is so that I can, if I choose, build the vast majority of my 
system without NEON instructions (and thus not take the overhead of VFP 
context save/restore during timeslices that don't use actual floating 
point) and still use a subset of those libraries from NEON-anointed 
binaries (assuming I define some sensible way for the kernel to make 
that distinction).

That isn't necessarily the right solution, of course -- either at a 
technical level or in the light of the LSB process and other 
inter-distro politics.  But maybe it's at least a more plausible use 
case for 2012 than NFS-mounting /usr/local on a mix of sun4c, sun4u, and 
IRIX workstations.  (That never did work quite right ...)

Cheers,
- Michael

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Carlos O'Donell]

On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers <joseph@codesourcery.com> wrote:
> (e) Existing practice for cases that do use different dynamic linkers is
> to use a separate library directory, not just dynamic linker name, as in
> lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to
> make two sets of libraries work in parallel if you have separate library
> directories like that.  So it would seem more appropriate to define a
> directory libhf for ARM (meaning you need a binutils patch as well to
> handle that directory, I think), and these different Debian-style names
> could be implemented separately in a multiarch patch if someone submits
> one that properly accounts for my review comments on previous patch
> versions (failure to produce such a fixed patch being why Debian multiarch
> directory support has not got into GCC so far).

The thread doesn't seem to be wrapping up, instead it appears to go in
circles :-)

As a glibc maintainer, when it comes to this issue, I am guided by:

(1) This is a distribution problem and the solution needs to come from
a consensus among the distributions.

(2) The gcc/glibc community should listen to the distributions.

The distributions have the most experience when it comes to
whole-system issues. I certainly don't have that experience.
Unfortunately *I* give the distributions a B- or C+ for communication.
Please make it easy for me to give you an A. It is exceedingly
difficult for me to review solutions that span multiple patches,
emails, mailing lists, and communities. The best way to avoid
rehashing old problems is to document the design and get sign off from
the interested parties.

If I see uncoordinated and conflicting responses from the
distributions... I get worried.

Is there a proposal on a wiki that begins to summarize the suggestions
and solution?

Cheers,
Carlos.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Tuesday 10 April 2012 01:17:36 Adam Conrad wrote:
> On Tue, Apr 10, 2012 at 12:01:57AM -0400, Mike Frysinger wrote:
> > On Monday 09 April 2012 19:31:40 Adam Conrad wrote:
> > > I realize that most people can't see past their own use case to
> > > understand why a unique location for linkers is helpful, useful, and
> > > important for some other people's use cases, but you either didn't
> > > read or chose to ignore why using multilib paths just plain doesn't
> > > scale past a single base architecture, and why that's a problem for
> > > people who aren't you.
> > 
> > and as already stated, the proposed paths here, free of multiarch
> > subpaths, satisfy the requirements that you've put forth
> 
> Like I said, then, you didn't actually read or understand why proposing
> multilib paths doesn't work.  You realize conceptually, I hope, that
> there's no guarantee of uniqueness in lib/lib64/lib32/libsf/libhf once
> you cross the base CPU architecture boundary, right?

i don't see this as a problem

> Sure, I said that /libhf/ld-linux.so.3 would *accidentally* work for
> us right now, due to sheer luck, and you're running with that as saying
> that we clearly have no problem here worth solving.

my point was: it works today and has no clashes.  that satisfies the "omg we 
have to ship something $now" and satisfies the requirement that only the Debian 
people are putting forth (and has already been violated by many targets): the 
ldso must be unique across all arches/multilibs.

> When the next architecture clashes with linkers on another (hint: it almost
> certainly will), do we get to argue about this all over again in six months,
> instead of codifying a new and saner practice now?

i don't buy that it'll happen that soon (since ldso's don't get generated 
quickly), but that is certainly plenty of time for the Debian project to 
attempt to convince everyone else that multiarch isn't a waste of time.  and 
does so without holding up moving forward with a unified arm hardfloat abi.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Mike Frysinger]

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

On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
> That way I can grandfather in binaries with ABI-ignorant
> hard-coded library paths, and still handle ISA variants.  The
> "extranoise" might be "neon", or "ssse3"

aren't ISA variants handled already by glibc ?  that's what the hwcaps stuff 
does -- you can put optimized versions in ISA-specific subdirs of the normal 
lib paths.  glibc will look for those first before falling back to the common 
libs.
-mike

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

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Richard Earnshaw]

On 05/04/12 14:34, Dennis Gilmore wrote:
> Fedora at least plans to not support installing hfp and sfp on the same
> system, while not completely decided I don't think we will be
> supporting running 32 bit arm binaries on 64 bit arm.  there is not
>  a legacy support use case that I can think of i.e. existing common
>  proprietary software. Though I imagine that we will use /lib64 for
>  consistency with existing 64 bit arches.

Regardless of what Fedora wants to support in its own environments, it's
important that what they do doesn't prevent other distros from
supporting multiple flavours if they so wish.  That means that there
must be at least common agreement on the fundamental naming of the
dynamic loader (assuming that the libraries themselves can be found via
some config magic).

R.

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Jeff Law]

On 04/10/2012 09:37 AM, Steve McIntyre wrote:
>
> Aargh. Again, use of a standard triplet for arm hard-float was agreed
> by all parties at the Plumbers' meeting last September. For exactly
> this reason. Now it seems that a number of people have totally ignored
> that consensus for the last six months.
More correctly, I don't think the ARM community disseminated the 
substance of that agreement to the GCC and other communities.

I think standardizing the triplet is a no-brainer and independent of 
whether or not the triplet shows up in the path/name of the dynamic 
linker.  Furthermore, the ARM GCC maintainers have the ability to 
standardize the triplet without a long debate on the subject.

Jeff

Re: [PATCH] ARM: Use different linker path for hardfloat ABI

[Michael K. Edwards]

On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Tuesday 10 April 2012 12:46:49 Michael Edwards wrote:
>> That way I can grandfather in binaries with ABI-ignorant
>> hard-coded library paths, and still handle ISA variants.  The
>> "extranoise" might be "neon", or "ssse3"
>
> aren't ISA variants handled already by glibc ?  that's what the hwcaps stuff
> does -- you can put optimized versions in ISA-specific subdirs of the normal
> lib paths.  glibc will look for those first before falling back to the common
> libs.
> -mike

I stand corrected with regard to non-ABI-altering ISA variations --
except for the nightmare that is Bionic libc, which is out of scope
for the present discussion.  Googling reminds me that Ulrich covered
all this ground in his original document for Linaro (which appears to
have moved onto the Debian wiki as
http://wiki.debian.org/Multiarch/LibraryPathOverview).

So this really is about nothing but freezing the full ABI name (vs. a
two-character suffix) into the path to ld.so.  And, of course, the
implied commitment to resolve any residual ambiguities in the ABI
(__cxa_pure_virtual(), anyone?) and to prioritize spec conformance
over bug-for-bug compatibility
(https://bugs.launchpad.net/gcc-linaro/+bug/952565).  When you give
something a detailed name, people are more likely to assume that it
has a detailed spec, interchangeable among distros and over time.  For
better or for worse, perpetuating the /lib?? kludge doesn't give that
impression.

Cheers,
- Michael