* Re: Phone call (was Re: Armhf dynamic linker path) [not found] ` <20120411223755.GD25263@einval.com> @ 2012-04-11 23:22 ` Michael Hope [not found] ` <CAHAq8pGbEtmu=QuOFGJpPCck6fFmb63Zm+Ax5B9Bg-m3U1UQ_w@mail.gmail.com> 2012-04-12 6:06 ` Jakub Jelinek 0 siblings, 2 replies; 13+ messages in thread From: Michael Hope @ 2012-04-11 23:22 UTC (permalink / raw) To: Steve McIntyre Cc: cross-distro, gcc-patches, Adam Conrad, libc-ports, linaro-toolchain, Jeff Law On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote: > On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: >> >>And here's the details as promised. >> >>I've started a wiki page at >> >>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >> >>with a strawman agenda for now, and a Doodle poll at >> >>http://www.doodle.com/93bitkqeb7auyxn7 >> >>to see when the best time is for the call on Thursday/Friday. Please >>fill in the times that work for you ASAP and I'll announce the result >>during Wednesday. Ideally we'd like stakeholders from all the relevant >>distros and the upstream toolchain developers to be there, able to >>represent their groups and (importantly) able to make a decision here >>on what we should do. >> >>Apologies for the short notice, but we need a decision quickly. > > And the best time turns out to be Friday at 15:00 UTC (16:00 BST, > 11:00 EDT etc.). Of the 10 people who responded in the poll, the only > person who can't make that time is Michael in .nz. Sorry, Michael. All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: * is similar to /lib/ld-x86-64.so.2 * keeps the libraries and loader in the same directory * doesn't invent a new /libhf directory * is easier to implement in GLIBC * is architecture and ABI unique * requires less change for distros where the hard float libraries are already in /lib I'm happy to do the GLIBC and GCC implementation. -- Michael ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CAHAq8pGbEtmu=QuOFGJpPCck6fFmb63Zm+Ax5B9Bg-m3U1UQ_w@mail.gmail.com>]
* Re: Phone call (was Re: Armhf dynamic linker path) [not found] ` <CAHAq8pGbEtmu=QuOFGJpPCck6fFmb63Zm+Ax5B9Bg-m3U1UQ_w@mail.gmail.com> @ 2012-04-12 0:16 ` Michael Hope 2012-04-12 1:15 ` Paulo César Pereira de Andrade [not found] ` <20120412003801.GS26898@dream.aleph1.co.uk> 0 siblings, 2 replies; 13+ messages in thread From: Michael Hope @ 2012-04-12 0:16 UTC (permalink / raw) To: Paulo César Pereira de Andrade Cc: Steve McIntyre, cross-distro, Adam Conrad, linaro-toolchain, gcc-patches, Jeff Law, libc-ports 2012/4/12 Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com>: > Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu: >> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote: >>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: >>>> >>>>And here's the details as promised. >>>> >>>>I've started a wiki page at >>>> >>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >>>> >>>>with a strawman agenda for now, and a Doodle poll at >>>> >>>>http://www.doodle.com/93bitkqeb7auyxn7 >>>> >>>>to see when the best time is for the call on Thursday/Friday. Please >>>>fill in the times that work for you ASAP and I'll announce the result >>>>during Wednesday. Ideally we'd like stakeholders from all the relevant >>>>distros and the upstream toolchain developers to be there, able to >>>>represent their groups and (importantly) able to make a decision here >>>>on what we should do. >>>> >>>>Apologies for the short notice, but we need a decision quickly. >>> >>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST, >>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only >>> person who can't make that time is Michael in .nz. Sorry, Michael. >> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: >> * is similar to /lib/ld-x86-64.so.2 >> * keeps the libraries and loader in the same directory >> * doesn't invent a new /libhf directory >> * is easier to implement in GLIBC >> * is architecture and ABI unique >> * requires less change for distros where the hard float libraries are >> already in /lib > > Sorry for more bikeshedding, but afaik rpm based distros are > using the armv7hl identifier, so it could as well be > > /lib/ld-linux-armv7hl.so.3 This includes the ABI (h), adds the endianess (l), and implies a architecture level (v7). The name for the most common configurations should be as short as possible so I'd rather drop the 'l' and add a 'b' or 'eb' if anyone wants a big endian distro in the future. The architecture level is a problem as the loader should also be valid on ARMv5 and ARMv6 hard float builds. Skype should be able to make a hard float binary that runs on everything, including a potential ARMv6 hard float RaspberryPi build. > Other variant could be > > /armv7hl-linux/lib/ld.so.3 This introduces both a new directory and a new style for naming :) -- Michael ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 0:16 ` Michael Hope @ 2012-04-12 1:15 ` Paulo César Pereira de Andrade 2012-04-12 1:40 ` Michael Hope [not found] ` <20120412003801.GS26898@dream.aleph1.co.uk> 1 sibling, 1 reply; 13+ messages in thread From: Paulo César Pereira de Andrade @ 2012-04-12 1:15 UTC (permalink / raw) To: Michael Hope Cc: Steve McIntyre, cross-distro, Adam Conrad, linaro-toolchain, gcc-patches, Jeff Law, libc-ports Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu: > 2012/4/12 Paulo César Pereira de Andrade > <paulo.cesar.pereira.de.andrade@gmail.com>: >> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu: >>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote: >>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: >>>>> >>>>>And here's the details as promised. >>>>> >>>>>I've started a wiki page at >>>>> >>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >>>>> >>>>>with a strawman agenda for now, and a Doodle poll at >>>>> >>>>>http://www.doodle.com/93bitkqeb7auyxn7 >>>>> >>>>>to see when the best time is for the call on Thursday/Friday. Please >>>>>fill in the times that work for you ASAP and I'll announce the result >>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant >>>>>distros and the upstream toolchain developers to be there, able to >>>>>represent their groups and (importantly) able to make a decision here >>>>>on what we should do. >>>>> >>>>>Apologies for the short notice, but we need a decision quickly. >>>> >>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST, >>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only >>>> person who can't make that time is Michael in .nz. Sorry, Michael. >>> >>> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: >>> * is similar to /lib/ld-x86-64.so.2 >>> * keeps the libraries and loader in the same directory >>> * doesn't invent a new /libhf directory >>> * is easier to implement in GLIBC >>> * is architecture and ABI unique >>> * requires less change for distros where the hard float libraries are >>> already in /lib >> >> Sorry for more bikeshedding, but afaik rpm based distros are >> using the armv7hl identifier, so it could as well be >> >> /lib/ld-linux-armv7hl.so.3 > > This includes the ABI (h), adds the endianess (l), and implies a > architecture level (v7). The name for the most common configurations > should be as short as possible so I'd rather drop the 'l' and add a > 'b' or 'eb' if anyone wants a big endian distro in the future. The > architecture level is a problem as the loader should also be valid on > ARMv5 and ARMv6 hard float builds. Skype should be able to make a > hard float binary that runs on everything, including a potential ARMv6 > hard float RaspberryPi build. This means ld.so (and what else? a skype binary should not come fully statically linked) should be built with -march=armv5te? That is, common denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set? AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r that has a div instruction in thumb mode). >> Other variant could be >> >> /armv7hl-linux/lib/ld.so.3 > > This introduces both a new directory and a new style for naming :) Well, I said I was sorry for more bikeshedding :-) > -- Michael Paulo ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 1:15 ` Paulo César Pereira de Andrade @ 2012-04-12 1:40 ` Michael Hope 2012-04-12 2:15 ` Paulo César Pereira de Andrade 0 siblings, 1 reply; 13+ messages in thread From: Michael Hope @ 2012-04-12 1:40 UTC (permalink / raw) To: Paulo César Pereira de Andrade Cc: Steve McIntyre, cross-distro, Adam Conrad, linaro-toolchain, gcc-patches, Jeff Law, libc-ports 2012/4/12 Paulo César Pereira de Andrade <paulo.cesar.pereira.de.andrade@gmail.com>: > Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu: >> 2012/4/12 Paulo César Pereira de Andrade >> <paulo.cesar.pereira.de.andrade@gmail.com>: >>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu: >>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote: >>>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: >>>>>> >>>>>>And here's the details as promised. >>>>>> >>>>>>I've started a wiki page at >>>>>> >>>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >>>>>> >>>>>>with a strawman agenda for now, and a Doodle poll at >>>>>> >>>>>>http://www.doodle.com/93bitkqeb7auyxn7 >>>>>> >>>>>>to see when the best time is for the call on Thursday/Friday. Please >>>>>>fill in the times that work for you ASAP and I'll announce the result >>>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant >>>>>>distros and the upstream toolchain developers to be there, able to >>>>>>represent their groups and (importantly) able to make a decision here >>>>>>on what we should do. >>>>>> >>>>>>Apologies for the short notice, but we need a decision quickly. >>>>> >>>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST, >>>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only >>>>> person who can't make that time is Michael in .nz. Sorry, Michael. >>>> >>>> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: >>>> * is similar to /lib/ld-x86-64.so.2 >>>> * keeps the libraries and loader in the same directory >>>> * doesn't invent a new /libhf directory >>>> * is easier to implement in GLIBC >>>> * is architecture and ABI unique >>>> * requires less change for distros where the hard float libraries are >>>> already in /lib >>> >>> Sorry for more bikeshedding, but afaik rpm based distros are >>> using the armv7hl identifier, so it could as well be >>> >>> /lib/ld-linux-armv7hl.so.3 >> >> This includes the ABI (h), adds the endianess (l), and implies a >> architecture level (v7). The name for the most common configurations >> should be as short as possible so I'd rather drop the 'l' and add a >> 'b' or 'eb' if anyone wants a big endian distro in the future. The >> architecture level is a problem as the loader should also be valid on >> ARMv5 and ARMv6 hard float builds. Skype should be able to make a >> hard float binary that runs on everything, including a potential ARMv6 >> hard float RaspberryPi build. > > This means ld.so (and what else? a skype binary should not come fully > statically linked) should be built with -march=armv5te? That is, common > denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set? > AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r > that has a div instruction in thumb mode). The architecture and feature set is a different topic and should be discussed by the distros but I'd rather finish the loader path one first. Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have all taken the opportunity to go to ARMv7 at the same time as switching to hard float. -- Michael ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 1:40 ` Michael Hope @ 2012-04-12 2:15 ` Paulo César Pereira de Andrade 0 siblings, 0 replies; 13+ messages in thread From: Paulo César Pereira de Andrade @ 2012-04-12 2:15 UTC (permalink / raw) To: Michael Hope Cc: Steve McIntyre, cross-distro, Adam Conrad, linaro-toolchain, gcc-patches, Jeff Law, libc-ports Em 11 de abril de 2012 22:39, Michael Hope <michael.hope@linaro.org> escreveu: > 2012/4/12 Paulo César Pereira de Andrade > <paulo.cesar.pereira.de.andrade@gmail.com>: >> Em 11 de abril de 2012 21:16, Michael Hope <michael.hope@linaro.org> escreveu: >>> 2012/4/12 Paulo César Pereira de Andrade >>> <paulo.cesar.pereira.de.andrade@gmail.com>: >>>> Em 11 de abril de 2012 20:22, Michael Hope <michael.hope@linaro.org> escreveu: >>>>> On 12 April 2012 10:38, Steve McIntyre <steve.mcintyre@linaro.org> wrote: >>>>>> On Wed, Apr 11, 2012 at 02:06:09AM +0100, Steve McIntyre wrote: >>>>>>> >>>>>>>And here's the details as promised. >>>>>>> >>>>>>>I've started a wiki page at >>>>>>> >>>>>>>https://wiki.linaro.org/OfficeofCTO/HardFloat/LinkerPathCallApr2012 >>>>>>> >>>>>>>with a strawman agenda for now, and a Doodle poll at >>>>>>> >>>>>>>http://www.doodle.com/93bitkqeb7auyxn7 >>>>>>> >>>>>>>to see when the best time is for the call on Thursday/Friday. Please >>>>>>>fill in the times that work for you ASAP and I'll announce the result >>>>>>>during Wednesday. Ideally we'd like stakeholders from all the relevant >>>>>>>distros and the upstream toolchain developers to be there, able to >>>>>>>represent their groups and (importantly) able to make a decision here >>>>>>>on what we should do. >>>>>>> >>>>>>>Apologies for the short notice, but we need a decision quickly. >>>>>> >>>>>> And the best time turns out to be Friday at 15:00 UTC (16:00 BST, >>>>>> 11:00 EDT etc.). Of the 10 people who responded in the poll, the only >>>>>> person who can't make that time is Michael in .nz. Sorry, Michael. >>>>> >>>>> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: >>>>> * is similar to /lib/ld-x86-64.so.2 >>>>> * keeps the libraries and loader in the same directory >>>>> * doesn't invent a new /libhf directory >>>>> * is easier to implement in GLIBC >>>>> * is architecture and ABI unique >>>>> * requires less change for distros where the hard float libraries are >>>>> already in /lib >>>> >>>> Sorry for more bikeshedding, but afaik rpm based distros are >>>> using the armv7hl identifier, so it could as well be >>>> >>>> /lib/ld-linux-armv7hl.so.3 >>> >>> This includes the ABI (h), adds the endianess (l), and implies a >>> architecture level (v7). The name for the most common configurations >>> should be as short as possible so I'd rather drop the 'l' and add a >>> 'b' or 'eb' if anyone wants a big endian distro in the future. The >>> architecture level is a problem as the loader should also be valid on >>> ARMv5 and ARMv6 hard float builds. Skype should be able to make a >>> hard float binary that runs on everything, including a potential ARMv6 >>> hard float RaspberryPi build. >> >> This means ld.so (and what else? a skype binary should not come fully >> statically linked) should be built with -march=armv5te? That is, common >> denominator should be vfpv3-d16, ldrd/strd and thumb2 instruction set? >> AFAIK, for "user level", armv6 with vfp is effectively amv7 (sans armv7-r >> that has a div instruction in thumb mode). > > The architecture and feature set is a different topic and should be > discussed by the distros but I'd rather finish the loader path one > first. Note that Fedora, Ubuntu, Debian, openSUSE, and Gentoo have > all taken the opportunity to go to ARMv7 at the same time as switching > to hard float. Ok. It obviously should be up to distros if they want the hardfp packages to be able to run on armv5 with a vfp :-) And so is for skype if they want it to run on such distro if it exists. Simpler alternate name would be /lib/ld-linux-armh.so.3 > -- Michael Paulo ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <20120412003801.GS26898@dream.aleph1.co.uk>]
* Re: Phone call (was Re: Armhf dynamic linker path) [not found] ` <20120412003801.GS26898@dream.aleph1.co.uk> @ 2012-04-12 1:27 ` Michael Hope 0 siblings, 0 replies; 13+ messages in thread From: Michael Hope @ 2012-04-12 1:27 UTC (permalink / raw) To: Wookey Cc: Paulo César Pereira de Andrade, cross-distro, Adam Conrad, linaro-toolchain, Jeff Law, gcc-patches, libc-ports On 12 April 2012 12:38, Wookey <wookey@wookware.org> wrote: > +++ Michael Hope [2012-04-12 12:16 +1200]: >> 2012/4/12 Paulo César Pereira de Andrade >> <paulo.cesar.pereira.de.andrade@gmail.com>: > >> >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: >> > Sorry for more bikeshedding, >> > /lib/ld-linux-armv7hl.so.3 >> I'd rather drop the 'l' > > We've already had the GNU triplet-name argument for this ABI. I don't > think having it again in order to use something slightly different for > the linker name is very helpful. > > Unless of course we find that was another chimera and in fact that's > not really agreed either... Sorry, I should have said that in my reply. I agree, the GNU triplet should be used. I couldn't resist going into the past-covered reasons why. -- Michael ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-11 23:22 ` Phone call (was Re: Armhf dynamic linker path) Michael Hope [not found] ` <CAHAq8pGbEtmu=QuOFGJpPCck6fFmb63Zm+Ax5B9Bg-m3U1UQ_w@mail.gmail.com> @ 2012-04-12 6:06 ` Jakub Jelinek [not found] ` <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com> ` (2 more replies) 1 sibling, 3 replies; 13+ messages in thread From: Jakub Jelinek @ 2012-04-12 6:06 UTC (permalink / raw) To: Michael Hope Cc: Steve McIntyre, cross-distro, gcc-patches, Adam Conrad, libc-ports, linaro-toolchain, Jeff Law On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote: > All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: The directory should be /libhf/ or /libhfp/ for that for consistency with all the other architectures. Note e.g. x86_64 dynamic linker is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. For distros that choose to multilib softfp vs. hardfp all the hardfp libraries would go into the usual */lib{qual} paths (for qual hf resp. hfp), for others /libhf can be a symlink to /lib or for those doing multiarch stuff can be a symlink to the multiarch location of the thing. I'm fine with arm and hf (resp. hfp) being mentioned in the name of the dynamic linker, but IMNSHO having there gnu and eabi strings is an overkill - why mention gnu there, when all the other architectures which also have GNU libc dynamic linkers don't? That part is implicit. And, EABI is implied by so.3, softfp dynamic linker for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old ABI is /lib/ld-linux.so.2. Jakub ^ permalink raw reply [flat|nested] 13+ messages in thread
[parent not found: <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com>]
* Re: Phone call (was Re: Armhf dynamic linker path) [not found] ` <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com> @ 2012-04-12 7:48 ` Jakub Jelinek 2012-04-12 17:48 ` Mike Frysinger 0 siblings, 1 reply; 13+ messages in thread From: Jakub Jelinek @ 2012-04-12 7:48 UTC (permalink / raw) To: Riku Voipio Cc: Michael Hope, cross-distro, Adam Conrad, linaro-toolchain, Steve McIntyre, Jeff Law, gcc-patches, libc-ports On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote: > On 12 April 2012 09:05, Jakub Jelinek <jakub@redhat.com> wrote: > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote: > >> All good. Â My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: > > > > The directory should be /libhf/ or /libhfp/ for that for consistency > > with all the other architectures. Â Note e.g. x86_64 dynamic linker > > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. > > For some value of consistency. x86_64, mips64, powerpc64 and sparc64 > install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on ia64 installs in /lib, because it isn't a multilibbed architecture. > s390x it is /lib/ld64.so.1 [1]. Ok, I forgot about this, I've tried to convince s390x folks to move it to /lib64/ld64.so.1 many years ago, but that just didn't happen, so /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1. Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker, while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc. That is an argument that perhaps /lib/ld-linux-armhf.so.3 could be acceptable too, as it would follow the s390x model, I wouldn't be terribly happy about that, but I could live with that. Jakub ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 7:48 ` Jakub Jelinek @ 2012-04-12 17:48 ` Mike Frysinger 2012-04-12 17:53 ` Jakub Jelinek 0 siblings, 1 reply; 13+ messages in thread From: Mike Frysinger @ 2012-04-12 17:48 UTC (permalink / raw) To: cross-distro, Jakub Jelinek Cc: Riku Voipio, Adam Conrad, linaro-toolchain, Steve McIntyre, Jeff Law, gcc-patches, libc-ports [-- Attachment #1: Type: Text/Plain, Size: 1637 bytes --] On Thursday 12 April 2012 03:47:29 Jakub Jelinek wrote: > On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote: > > On 12 April 2012 09:05, Jakub Jelinek <jakub@redhat.com> wrote: > > > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote: > > >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: > > > The directory should be /libhf/ or /libhfp/ for that for consistency > > > with all the other architectures. Note e.g. x86_64 dynamic linker > > > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. > > > > For some value of consistency. x86_64, mips64, powerpc64 and sparc64 > > install to /lib64. But on ia64 it is /lib/ld-linux-ia64.so.2 and on > > ia64 installs in /lib, because it isn't a multilibbed architecture. because distros choose not to support it. in first gen chips, there was hardware support for running x86. so if we were to be strict, there should have been /libia64/ (or whatever) while the current x86 32bit code would stay in /lib/. but no distro was interested in supporting that (probably due to the 32bit x86 layers being balls-ass slow), so it never happened. > > s390x it is /lib/ld64.so.1 [1]. > > Ok, I forgot about this, I've tried to convince s390x folks to move it > to /lib64/ld64.so.1 many years ago, but that just didn't happen, so > /lib/ld64.so.1 is just a symlink to /lib64/ld64.so.1. > Upstream glibc binaries use /lib64/ld64.so.1 as their dynamic linker, > while all other packages use /lib/ld64.so.1 as that is hardcoded in gcc. i always thought this was weird. glad to know i'm not the only one :). -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 17:48 ` Mike Frysinger @ 2012-04-12 17:53 ` Jakub Jelinek 2012-04-12 18:14 ` Mike Frysinger 0 siblings, 1 reply; 13+ messages in thread From: Jakub Jelinek @ 2012-04-12 17:53 UTC (permalink / raw) To: Mike Frysinger Cc: cross-distro, Riku Voipio, Adam Conrad, linaro-toolchain, Steve McIntyre, Jeff Law, gcc-patches, libc-ports On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote: > > ia64 installs in /lib, because it isn't a multilibbed architecture. > > because distros choose not to support it. in first gen chips, there was > hardware support for running x86. so if we were to be strict, there should > have been /libia64/ (or whatever) while the current x86 32bit code would stay > in /lib/. but no distro was interested in supporting that (probably due to > the 32bit x86 layers being balls-ass slow), so it never happened. We even carried patches (not applied) for lib64 ia64 support in our binutils/glibc/gcc for a while, but the final decision after these were written was that it is going to stay in /lib. Jakub ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 17:53 ` Jakub Jelinek @ 2012-04-12 18:14 ` Mike Frysinger 0 siblings, 0 replies; 13+ messages in thread From: Mike Frysinger @ 2012-04-12 18:14 UTC (permalink / raw) To: Jakub Jelinek Cc: cross-distro, Riku Voipio, Adam Conrad, linaro-toolchain, Steve McIntyre, Jeff Law, gcc-patches, libc-ports [-- Attachment #1: Type: Text/Plain, Size: 1311 bytes --] On Thursday 12 April 2012 13:53:13 Jakub Jelinek wrote: > On Thu, Apr 12, 2012 at 01:49:16PM -0400, Mike Frysinger wrote: > > > ia64 installs in /lib, because it isn't a multilibbed architecture. > > > > because distros choose not to support it. in first gen chips, there was > > hardware support for running x86. so if we were to be strict, there > > should have been /libia64/ (or whatever) while the current x86 32bit > > code would stay in /lib/. but no distro was interested in supporting > > that (probably due to the 32bit x86 layers being balls-ass slow), so it > > never happened. > > We even carried patches (not applied) for lib64 ia64 support in our > binutils/glibc/gcc for a while, but the final decision after these were > written was that it is going to stay in /lib. true, it would have been /lib64/ since the hardware doesn't the 64bit extensions for x86. but i think the point still stands that using /lib/ for the new hardfloat ABI is OK rather than needing to go the /libhf/ multilib route. and, if it turns out that we were being too optimistic and we do actually want soft/hard float multilib, i don't think this will be a blocker. as mentioned, the s390x guys have been bad and it hasn't been a blocker for s390/s390x multilib with them :). -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 6:06 ` Jakub Jelinek [not found] ` <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com> @ 2012-04-12 17:46 ` Mike Frysinger 2012-04-12 20:33 ` Paulo César Pereira de Andrade 2 siblings, 0 replies; 13+ messages in thread From: Mike Frysinger @ 2012-04-12 17:46 UTC (permalink / raw) To: cross-distro, Jakub Jelinek Cc: Michael Hope, Adam Conrad, linaro-toolchain, Steve McIntyre, Jeff Law, gcc-patches, libc-ports [-- Attachment #1: Type: Text/Plain, Size: 1361 bytes --] On Thursday 12 April 2012 02:05:23 Jakub Jelinek wrote: > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote: > > All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: > > The directory should be /libhf/ or /libhfp/ for that for consistency > with all the other architectures. i think the idea was that no one is looking to do multilib here. so we won't have softfloat in /lib/ and hardfloat in /libhf/. we're just changing the ldso to reflect a change in the ABI. you could also make this argument for EABI and OABI -- the EABI ldso should not be in /lib/. but since we've got OABI and EABI both in /lib/ and people are happy with that, as well as the hardfloat ldso in /lib/, there's no need for a sep /libhf/. > I'm fine with arm and hf (resp. hfp) being mentioned in the name of > the dynamic linker, but IMNSHO having there gnu and eabi strings > is an overkill - why mention gnu there, when all the other > architectures which also have GNU libc dynamic linkers don't? That > part is implicit. And, EABI is implied by so.3, softfp dynamic linker > for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old > ABI is /lib/ld-linux.so.2. i have no opinion either way here. uClibc has already opted to name things with "-uClibc-" in them, so we're clear of collisions there. -mike [-- Attachment #2: This is a digitally signed message part. --] [-- Type: application/pgp-signature, Size: 836 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: Phone call (was Re: Armhf dynamic linker path) 2012-04-12 6:06 ` Jakub Jelinek [not found] ` <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com> 2012-04-12 17:46 ` Mike Frysinger @ 2012-04-12 20:33 ` Paulo César Pereira de Andrade 2 siblings, 0 replies; 13+ messages in thread From: Paulo César Pereira de Andrade @ 2012-04-12 20:33 UTC (permalink / raw) To: Jakub Jelinek Cc: Michael Hope, Steve McIntyre, cross-distro, gcc-patches, Adam Conrad, libc-ports, linaro-toolchain, Jeff Law Em 12 de abril de 2012 03:05, Jakub Jelinek <jakub@redhat.com> escreveu: > On Thu, Apr 12, 2012 at 11:22:13AM +1200, Michael Hope wrote: >> All good. My vote is for /lib/ld-arm-linux-gnueabihf.so.3 as it: > > The directory should be /libhf/ or /libhfp/ for that for consistency > with all the other architectures. Note e.g. x86_64 dynamic linker > is /lib64/ld-linux-x86-64.so.2, not /lib/ld-linux-x86-64.so.2. > For distros that choose to multilib softfp vs. hardfp all the hardfp > libraries would go into the usual */lib{qual} paths (for qual hf resp. > hfp), for others /libhf can be a symlink to /lib or for those doing > multiarch stuff can be a symlink to the multiarch location of the thing. I would feel a bit better with a commitment for multilib if using /libhf, but really just to make users life easier. Providing the infrastructure (by having multilib packages) is asking for it to be used. In the skype example, if multilib is supported by all distros, skype may as well provide only an armv5te software float build for linux arm. This is the reason, for example, to install skype in my x86_64 computer I need to install 32 bit qt, alsa, X11 libraries, etc to be able to install x86 skype. > I'm fine with arm and hf (resp. hfp) being mentioned in the name of > the dynamic linker, but IMNSHO having there gnu and eabi strings > is an overkill - why mention gnu there, when all the other > architectures which also have GNU libc dynamic linkers don't? That > part is implicit. And, EABI is implied by so.3, softfp dynamic linker > for EABI is /lib/ld-linux.so.3 while softfp dynamic linker for the old > ABI is /lib/ld-linux.so.2. > > Jakub Paulo ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2012-04-12 20:33 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20120331103406.GA17776@einval.com> [not found] ` <201204100019.13472.vapier@gentoo.org> [not found] ` <4F83B5AD.3010302@redhat.com> [not found] ` <201204100033.08853.vapier@gentoo.org> [not found] ` <4F83B939.10205@redhat.com> [not found] ` <4F84AC96.6020500@redhat.com> [not found] ` <20120411010608.GC25263@einval.com> [not found] ` <20120411223755.GD25263@einval.com> 2012-04-11 23:22 ` Phone call (was Re: Armhf dynamic linker path) Michael Hope [not found] ` <CAHAq8pGbEtmu=QuOFGJpPCck6fFmb63Zm+Ax5B9Bg-m3U1UQ_w@mail.gmail.com> 2012-04-12 0:16 ` Michael Hope 2012-04-12 1:15 ` Paulo César Pereira de Andrade 2012-04-12 1:40 ` Michael Hope 2012-04-12 2:15 ` Paulo César Pereira de Andrade [not found] ` <20120412003801.GS26898@dream.aleph1.co.uk> 2012-04-12 1:27 ` Michael Hope 2012-04-12 6:06 ` Jakub Jelinek [not found] ` <CAAqcGHmJL4jiL8u3MMqw_B38m1HHbVGdZouiEqJV3o_JkLPf5g@mail.gmail.com> 2012-04-12 7:48 ` Jakub Jelinek 2012-04-12 17:48 ` Mike Frysinger 2012-04-12 17:53 ` Jakub Jelinek 2012-04-12 18:14 ` Mike Frysinger 2012-04-12 17:46 ` Mike Frysinger 2012-04-12 20:33 ` Paulo César Pereira de Andrade
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).