Re: Phone call (was Re: Armhf dynamic linker path)
On 12/04/12 19:29, Dennis Gilmore wrote: off topic but i find aarch64 weird and too generic is it arm alpha amd atom. That's only 'cos it's new. It's no different from names like ia64. R. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
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
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On 12 April 2012 09:05, Jakub Jelinek ja...@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
s390x it is /lib/ld64.so.1 [1].
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.
My qualm with /libhf is that it is currently used by nobody. But in a
way it is fair compromise where no distro gets preferential treatment
- everyone will have to move files around.
Riku
[1] https://wiki.linaro.org/RikuVoipio/LdSoTable
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On Thu, Apr 12, 2012 at 10:33:08AM +0300, Riku Voipio wrote: On 12 April 2012 09:05, Jakub Jelinek ja...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
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 signature.asc Description: This is a digitally signed message part. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
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 ja...@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 signature.asc Description: This is a digitally signed message part. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
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 signature.asc Description: This is a digitally signed message part. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On Wed, 11 Apr 2012 20:44:22 -0300 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com wrote: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 I dont see the need for linux there /lib/ld-armv7hl.so.3 or just /lib/ld-armhfp.so.3 64 bit could be /lib64/ld-armhfp.so.3 or /lib64/ld-aarch64.so.3 off topic but i find aarch64 weird and too generic is it arm alpha amd atom. we shouldnt use any triplet since they are not standard between distros, Dennis ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
Em 12 de abril de 2012 03:05, Jakub Jelinek ja...@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
___
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 Other variant could be /armv7hl-linux/lib/ld.so.3 but that only if one wants to implement multiarch with sysroot set to /armv7hl-linux, but that creates several other issues... I'm happy to do the GLIBC and GCC implementation. -- Michael ___ cross-distro mailing list cross-dis...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/cross-distro Paulo ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
+++ Michael Hope [2012-04-12 12:16 +1200]: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@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... Wookey -- Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM http://wookware.org/ ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
Em 11 de abril de 2012 21:16, Michael Hope michael.h...@linaro.org escreveu: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On 04/11/2012 05:16 PM, Michael Hope wrote: 2012/4/12 Paulo César Pereira de Andrade /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. In Fedora we specifically mean VFPv3-D16 when we're talking about hard float. This is the lowest common denominator for us. If you want to support armv5hl, armv6hl, and armv7hl as all being possible (whatever string you like to represent it) that's good to know because it's beyond what we're contemplating. -- Brendan Conoboy / Red Hat, Inc. / b...@redhat.com ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 21:16, Michael Hope michael.h...@linaro.org escreveu: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
Em 11 de abril de 2012 22:39, Michael Hope michael.h...@linaro.org escreveu: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 21:16, Michael Hope michael.h...@linaro.org escreveu: 2012/4/12 Paulo César Pereira de Andrade paulo.cesar.pereira.de.andr...@gmail.com: Em 11 de abril de 2012 20:22, Michael Hope michael.h...@linaro.org escreveu: On 12 April 2012 10:38, Steve McIntyre steve.mcint...@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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Phone call (was Re: Armhf dynamic linker path)
On Apr 11, 2012, at 7:22 PM, Michael Hope wrote: 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. I'm happy with your proposal, as I am with any of the others that result in a /lib path (our guys will accept that) that contains enough uniqueness that there won't be a path clash later. Sure, Jakub will probably argue that .so.3 already implies gnueabi so we can drop that, and we can screw around with this some more, but you are on the right track IMO. Jon. ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
