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.
>
>
67 matches
Mail list logo
