Re: Phone call (was Re: Armhf dynamic linker path)
On 12 April 2012 09:05, 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. 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 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
[ANNOUNCE] Linaro QEMU 2012.04 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro QEMU 2012.04. Linaro QEMU 2012.04 is the latest monthly release of qemu-linaro. Based off upstream (trunk) QEMU, it includes a number of ARM-focused bug fixes and enhancements. New in this month's release: - ppoll syscall now supported in ARM linux-user mode - the SETEND instruction in the Thumb encoding now UNDEFs to match behaviour for the ARM encoding - the OMAP36xx UART FIFO status registers are now implemented (thanks to Jan Vesely) Known issues: - Graphics do not work for OMAP3 based models (beagle, overo) with 11.10 Linaro images. - Audio may not work on Versatile Express models with the latest Linaro kernel/hardware packs (LP:977610). The source tarball is available at: https://launchpad.net/qemu-linaro/+milestone/2012.03 More information on Linaro QEMU is available at: https://launchpad.net/qemu-linaro ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: [ANNOUNCE] Linaro QEMU 2012.04 released
On 12 April 2012 10:55, Peter Maydell wrote: > The Linaro Toolchain Working Group is pleased to announce the release of > Linaro QEMU 2012.04. > The source tarball is available at: > https://launchpad.net/qemu-linaro/+milestone/2012.03 This should of course be: https://launchpad.net/qemu-linaro/+milestone/2012.04 Apologies for the error. -- PMM ___ 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 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 wrote: > Em 11 de abril de 2012 20:22, Michael Hope > escreveu: > > On 12 April 2012 10:38, Steve McIntyre > > 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
getting armv7 linker to emit armv4t thumb interworking
I have a cross toolchain I configured with "--with-arch=armv7-a --with-cpu=cortex-a9 --with-tune=cortex-a9" and I want the linker to emit armv4t compatible thumb interworking, but I can't seem to get it to. I noticed that if I create a armv4t toolchain with "--with-arch=armv4t --with-cpu=arm7tdmi --with-tune=arm7tdmi" and then I pass "--use-blx" to the linker it will emit armv7 thumb interworking. There doesn't seem to be any inverse "--no-use-blx" type switch though. Is this a bug/limitation of the linker or am I misunderstanding something? -Allen nvpublic ___ 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 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
Linaro GDB 7.4 2012.04 released
The Linaro Toolchain Working Group is pleased to announce the release of Linaro GDB 7.4 2012.04. Linaro GDB 7.4 2012.04 is the second release in the 7.4 series. Based off the latest GDB 7.4, it includes a number of ARM-focused bug fixes and enhancements. Interesting changes include: * gdbserver can now be compiled with Android's toolchain. * Additional fixes from the GDB 7.4 branch, one of them being that it doesn't require makeinfo to build anymore. The source tarball is available at: https://launchpad.net/gdb-linaro/+milestone/7.4-2012.04 More information on Linaro GDB is available at: https://launchpad.net/gdb-linaro -- []'s Thiago Jung Bauermann Linaro Toolchain Working Group ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
