On Tue, Apr 10, 2012 at 8:15 PM, Mike Frysinger 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
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.
M
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
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 stuf
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
On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers 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
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
On Tue, Apr 10, 2012 at 09:32:22AM -0500, Dennis Gilmore wrote:
>On Tue, 10 Apr 2012 12:18:51 +0300
>Konstantinos Margaritis wrote:
>
>> On Tue, 10 Apr 2012 07:36:07 +0200
>> Jakub Jelinek wrote:
>> > We really want consistency about the dynamic linker names etc.
>> > across different targets and
On Tue, 10 Apr 2012 09:32:22 -0500
Dennis Gilmore 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
On Tue, 10 Apr 2012 12:18:51 +0300
Konstantinos Margaritis wrote:
> On Tue, 10 Apr 2012 07:36:07 +0200
> Jakub Jelinek wrote:
> > We really want consistency about the dynamic linker names etc.
> > across different targets and sneaking silently multiarch paths on
> > one architecture would make i
On Tue, 10 Apr 2012 07:36:07 +0200
Jakub Jelinek 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.
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 bound
On Tue, Apr 10, 2012 at 05:17:36AM +, 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 lin
Em 9 de abril de 2012 17:48, Adam Conrad escreveu:
> 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
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 us
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
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, i
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// is really the only one i
> > don't think doesn't belong.
>
>
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 multi
On Mon, Apr 09, 2012 at 07:14:45PM -0400, Mike Frysinger wrote:
>
> again, saying "/lib//" 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
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),
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 p
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.
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// 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 raisi
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 t
On Thu, Apr 05, 2012 at 01:16:27PM +1200, Michael Hope wrote:
>On 5 April 2012 12:07, Joseph S. Myers 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 throu
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
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 th
Em 5 de abril de 2012 12:09, Mike Frysinger 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 so
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
> i
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 othe
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 buil
On Tue, Apr 03, 2012 at 10:56:18PM +, 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
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 m
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
On 04/05/2012 03:30 PM, 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
Hi Den
El Wed, 4 Apr 2012 08:54:12 +0200
Jakub Jelinek 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
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
Hi Dennis,
One potential problem that is born from the
On Wed, Apr 04, 2012 at 02:39:58PM +1200, Michael Hope wrote:
> On 4 April 2012 10:56, Joseph S. Myers wrote:
> > On Tue, 3 Apr 2012, Michael Hope wrote:
> >
> >> +#define GLIBC_DYNAMIC_LINKER \
> >> + "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
> >> + %{mfloat-abi=hard:" GLIBC_DYNA
On 5 April 2012 12:07, Joseph S. Myers 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 w
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 GC
On 4 April 2012 21:06, Joseph S. Myers 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 A
On 4 April 2012 18:54, Jakub Jelinek 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
On Wed, 4 Apr 2012 09:06:05 + (UTC)
"Joseph S. Myers" 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
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) an
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 speci
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
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 woul
On 4 April 2012 10:56, Joseph S. Myers 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:" GLI
2012/4/4 Paulo César Pereira de Andrade
:
> Em 3 de abril de 2012 20:48, Michael Hope escreveu:
>> 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 rel
Em 3 de abril de 2012 20:48, Michael Hope escreveu:
> On 4 April 2012 11:11, 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 t
On Wed, Apr 4, 2012 at 12:48 AM, Michael Hope wrote:
> On 4 April 2012 11:11, 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
On 4 April 2012 11:11, 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.
>> >
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 bi
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
On 4 April 2012 04:17, Andrew Haley 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-gnueab
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
>>>
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
On Tue, Apr 03, 2012 at 03:29:06PM +1200, Michael Hope wrote:
> On 3 April 2012 09:06, 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
>
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 Debianis
On 03/04/12 11:51, Richard Guenther wrote:
> On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw 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 frazi
On Tue, Apr 3, 2012 at 12:45 PM, Richard Earnshaw 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 p
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
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
On 3 April 2012 09:06, 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 differenc
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 wh
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.
>
>
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
* config/arm/lin
68 matches
Mail list logo
