Re: Armhf dynamic linker path
On Mon, Apr 2, 2012 at 09:19, Riku Voipio wrote: > On 31 March 2012 19:52, Dennis Gilmore wrote: >> Linaro Connect and other events are probably the worst place for such >> decisions and discussions to be made. though maybe there is not a good >> place. the wider community needs to be engaged for greatest acceptance. >> otherwise then if falls into the vacuum of those attending the events. >> Like I said its not that it could never happen just that its not been >> discussed at all. so requesting that distros adopt it is a bit harsh >> and unrealistic. > > At Linaro conference the need for changing linker path was agreed on, > as well as the need to get a wide community agreement on it. To do the > latter, an ARM minisummit was organized on at Plumbers 2011 [1]. > Invites to wide range communities and distributions were sent, and for > most someone attended. For the people not able to join physically, a > call-in line was organized (I was on the call for example). With the > expectation that people who attended in face or on call would convey > the message back to their own communities. This didn't seemingly > happen for everyone it seems. i agree that the ldso needs changing to something unique so everyone can start off on the same page with a sane path. i don't think forcing everyone into the multi-arch stuff that debian is deploying makes sense though. this seems like a fairly behind-the-back maneuver in terms of slipping it into mainline. -mike ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote: > On 02.04.2012 21:46, Jon Masters wrote: >> On 04/02/2012 03:04 PM, Mike Frysinger wrote: >>> On Mon, Apr 2, 2012 at 09:19, Riku Voipio wrote: >>>> On 31 March 2012 19:52, Dennis Gilmore wrote: >>>>> Linaro Connect and other events are probably the worst place for such >>>>> decisions and discussions to be made. though maybe there is not a good >>>>> place. the wider community needs to be engaged for greatest acceptance. >>>>> otherwise then if falls into the vacuum of those attending the events. >>>>> Like I said its not that it could never happen just that its not been >>>>> discussed at all. so requesting that distros adopt it is a bit harsh >>>>> and unrealistic. >>>> >>>> At Linaro conference the need for changing linker path was agreed on, >>>> as well as the need to get a wide community agreement on it. To do the >>>> latter, an ARM minisummit was organized on at Plumbers 2011 [1]. >>>> Invites to wide range communities and distributions were sent, and for >>>> most someone attended. For the people not able to join physically, a >>>> call-in line was organized (I was on the call for example). With the >>>> expectation that people who attended in face or on call would convey >>>> the message back to their own communities. This didn't seemingly >>>> happen for everyone it seems. >>> >>> >>> i agree that the ldso needs changing to something unique so everyone >>> can start off on the same page with a sane path. i don't think >>> forcing everyone into the multi-arch stuff that debian is deploying >>> makes sense though. this seems like a fairly behind-the-back maneuver >>> in terms of slipping it into mainline. >> >> >> Right. For clarification, we (Fedora) have no plans to do multi-arch >> (though I know many of us are personally interested in the idea). That >> doesn't mean we can't have a platform specific linker path change. > > yes, this was brought up at Linaro Connect as well; having the ldso name in > a multiarch location doesn't mean that anything else needs to be in this > location. while true, it seems like /lib/ vs /lib// needs to be handled by the multiarch people regardless (for historical support), while non-multiarch peeps never have /lib/xxx/ subdirs. i know it's a bit of bike shedding, but if the mainline standard is /lib/ and multiarch peeps have to deal with that already, it'd make more sense to stick with /lib/. in the last patch it seemed like only the path differed, but the ldso was still named "ld-linux.so.3", but maybe i misread it and/or confused it with an old patch. the new HF ldso will always be "ld-linux.so.3" while the old who-knows-what-ABI-it-actually-is name will be "ld-linux.so.2" ? > I am a bit surprised that this comes up again, and I really would > like to settle this within the next two weeks. Note that Ubuntu 11.10 > already did ship with this ldso name based on these discussions. Jon, > afaicr I did ask this very same question (if the ldso name in a multiarch > location would be acceptable) at Linaro Connect in August 2011 in Cambridge, > and afaicr you didn't object to this path. i've never attended a conference in Cambridge (US or UK). maybe you're remembering something else ? -mike ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Armhf dynamic linker path
On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote: > On 3 April 2012 02:56, Mike Frysinger wrote: > > On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote: > >> yes, this was brought up at Linaro Connect as well; having the ldso name > >> in a multiarch location doesn't mean that anything else needs to be in > >> this location. > > > > while true, it seems like /lib/ vs /lib// needs > > to be handled by the multiarch people regardless (for historical > > support), while non-multiarch peeps never have /lib/xxx/ subdirs. > > > > i know it's a bit of bike shedding, but if the mainline standard is > > /lib/ and multiarch peeps have to deal with that already, it'd > > make more sense to stick with /lib/. > > For some value of "mainline standard": > > https://wiki.linaro.org/RikuVoipio/LdSoTable > > Quite clear there has been no effort in naming except in the few cases > "something" was hacked in to allow coinstall of 64bit binaries. we all agree arm's current situation is f-ed. however, i don't agree with your analysis of any of the other targets. they all look sane to me. > The choice of using multiarch path for armhf linker path was agreed > mostly because 1) people agreed that having the possibility of armhf > and armel binaries on the same systems is useful and 2) nobody > proposed anything else. i don't see value in having multiple endians being active simultaneously. it might make for a fun exercise, but people won't deploy systems with them both installed. after all, the kernel isn't bi-endian on the fly. -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: Armhf dynamic linker path
On Wednesday 04 April 2012 21:31:20 dann frazier wrote: > On Wed, Apr 04, 2012 at 09:18:13PM -0400, Mike Frysinger wrote: > > On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote: > > > On 3 April 2012 02:56, Mike Frysinger wrote: > > > > On Mon, Apr 2, 2012 at 17:15, Matthias Klose wrote: > > > >> yes, this was brought up at Linaro Connect as well; having the ldso > > > >> name in a multiarch location doesn't mean that anything else needs > > > >> to be in this location. > > > > > > > > while true, it seems like /lib/ vs /lib// > > > > needs to be handled by the multiarch people regardless (for > > > > historical support), while non-multiarch peeps never have /lib/xxx/ > > > > subdirs. > > > > > > > > i know it's a bit of bike shedding, but if the mainline standard is > > > > /lib/ and multiarch peeps have to deal with that already, it'd > > > > make more sense to stick with /lib/. > > > > > > The choice of using multiarch path for armhf linker path was agreed > > > mostly because 1) people agreed that having the possibility of armhf > > > and armel binaries on the same systems is useful and 2) nobody > > > proposed anything else. > > > > i don't see value in having multiple endians being active simultaneously. > > it might make for a fun exercise, but people won't deploy systems with > > them both installed. after all, the kernel isn't bi-endian on the fly. > > Do you mean multiple ABIs? no -- i said "endian" here a few times. i agree that multiple ABIs makes sense. (let's not pointlessly nitpick endian encoding as part of the ABI and just go with what people more commonly use.) > The kernel does support both EABI (Debian's armel) and EABI/Hardfloat > (Debian's armhf) concurrently too bad the OABI shim is buggy :( -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: Armhf dynamic linker path
On Wednesday 04 April 2012 22:48:34 Wookey wrote: > Mike Frysinger [2012-04-02 19:56 -0400]: > > >>> i agree that the ldso needs changing to something unique so everyone > > >>> can start off on the same page with a sane path. i don't think > > >>> forcing everyone into the multi-arch stuff that debian is deploying > > >>> makes sense though. this seems like a fairly behind-the-back > > >>> maneuver in terms of slipping it into mainline. > > >> > > >> Right. For clarification, we (Fedora) have no plans to do multi-arch > > >> (though I know many of us are personally interested in the idea). That > > >> doesn't mean we can't have a platform specific linker path change. > > > > > > yes, this was brought up at Linaro Connect as well; having the ldso > > > name in a multiarch location doesn't mean that anything else needs to > > > be in this location. > > > > while true, it seems like /lib/ vs /lib// needs > > to be handled by the multiarch people regardless (for historical > > support), while non-multiarch peeps never have /lib/xxx/ subdirs. > > It isn't helpful to think about this as a 'multiarch' thing. It's > about having a unique linker path everyone uses for a particular ABI > so that binaries can be run on more than one distro. > > The use of a GNU triplet to distinguish the 'armhf' ABI linker path is > just a sensible way to do it (and it'll work for future arches/ABIs > too). That brings no multiarchness at all with it. trying to paint the use of a triplet in the path as any other than multiarch is bunk. as Joseph explained in detail, there already is a standard in mainline tools. if you want to change the standard, then propose something consistently for everyone. backdooring it for 1 target is not the way. > > i know it's a bit of bike shedding, but if the mainline standard is > > /lib/ and multiarch peeps have to deal with that already, it'd > > make more sense to stick with /lib/. > > No-one can 'deal' with the fact that you can't have binaries of > different ABIs work in the same filesystem unless they have unique > linker paths. And if we want 3rd-party-shipped binaries to work on > (say, Redhat and Debian and Ubuntu and Fedora (which we do), those > distros need to be using the same linker path). > > So that requires a path that is unique across ABIs and common across > distros. everyone has already agreed that we should have a new unique ldso name for armv7/hardfloat. so you're not really stating anything new here. -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: Armhf dynamic linker path
On Thursday 05 April 2012 05:06:43 Riku Voipio wrote: > On 5 April 2012 04:18, Mike Frysinger wrote: > > On Tuesday 03 April 2012 04:06:01 Riku Voipio wrote: > >> The choice of using multiarch path for armhf linker path was agreed > >> mostly because 1) people agreed that having the possibility of armhf > >> and armel binaries on the same systems is useful and 2) nobody > >> proposed anything else. > > > > i don't see value in having multiple endians being active simultaneously. > > it might make for a fun exercise, but people won't deploy systems with > > them both installed. after all, the kernel isn't bi-endian on the fly. > > Sorry for being ambigous. With "armel" I mean arm eabi with softfloat > abi. What people agreed was useful was supporting those binaries along > with eabi hardfloat binaries "armhf". sure, we all agree on that :) -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: Armhf dynamic linker path
On Monday 09 April 2012 15:47:56 Adam Conrad wrote: > are you not just as much hindering Debian over nothing more than a path to a > single file? nope. sounds more like self inflicted pain. > To be very, very, very clea here. multilib can not solve the "different > base arches on one system problem". lib/lib32/lib64/libhf/libsf will > overlap as soon as you have more than one of x86, arm, power, mips, etc. no one is saying it can (or at least, i'm certainly not). my point is that many people don't see this as a "problem". -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: Armhf dynamic linker path
On Tuesday 10 April 2012 00:23:09 Jeff Law wrote: > On 04/09/2012 10:19 PM, Mike Frysinger wrote: > > On Monday 09 April 2012 15:47:56 Adam Conrad wrote: > >> To be very, very, very clea here. multilib can not solve the "different > >> base arches on one system problem". lib/lib32/lib64/libhf/libsf will > >> overlap as soon as you have more than one of x86, arm, power, mips, etc. > > > > no one is saying it can (or at least, i'm certainly not). my point is > > that many people don't see this as a "problem". > > Don't the multilib paths contain enough information to handle this? > They certainly have in the past as I can recall building toolchains that > handled several architectures within power, arm & mips families in the past his point is you can't install multiple architectures into the same root. alpha, arm oabi, and m32r for example have ldso set to /lib/ld-linux.so.2. a quick grep of GLIBC_DYNAMIC_LINKER in gcc's config/ tree shows other collisions. > Is the problem here that glibc simply isn't building multilib paths in > the same way that GCC has for the last 15 years? afaik, glibc and gcc should be in sync ... can't say i've noticed issues with all the arches Gentoo supports. -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: Armhf dynamic linker path
On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote: > We understand that not everybody may want or see the need for this for > themselves. We *really* get that. But we want it to be possible for > *us* to do it, and an ultra-important part of that is to have unique > loader paths wherever possible. Hence the discussion over the location > for the arm hard-float linker. We've built our systems using the > multi-arch path as that worked well for us and doesn't hurt anybody > else. There are problems with some of the other options here: > > * /lib/ld-linux.so.3 no one suggested this > * /libhf/ld-linux.so.3 > - it could readily clash with a future hard-float platform; look > how /lib64/* could clash with amd64/ARMv8/ppc64/sparc64 all > populating it in the near future > > * /lib/ld-linux-hf.so.3 > - similar problem so you're saying Debian would never accept any ldso path for any arch on the future possibility that it could collide with another target ? that's a bit unreasonable. > * /lib/ld-linux-$triplet.so.3 > - could work fine, so long as we can agree on triplets kind of a waste of space, and the definition of "triplet" is vague, and in your example here, the word "linux" uselessly appears twice. once the duplicate "linux" word is fixed, i wouldn't fight this. > In Debian and Ubuntu, we have implemented the last one of these three > and it's working fine for us. We had understood that in previous > cross-distro discussions (e.g. at Plumbers last year) there was > agreement on this, but we're now seeing dissent. Ubuntu are expecting > (by the end of this month) to be the first distro to ship a stable > release using the hard-float ABI on ARM, so it's unfortunate that this > argument is happening now. one of the downsides of traveling down a path and upstreaming as an after thought -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: Armhf dynamic linker path
On Wednesday 11 April 2012 05:47:29 Steve McIntyre wrote: > On Tue, Apr 10, 2012 at 11:01:47PM -0400, Mike Frysinger wrote: > >On Tuesday 10 April 2012 06:42:04 Steve McIntyre wrote: > >> * /lib/ld-linux-$triplet.so.3 > >> - could work fine, so long as we can agree on triplets > > > >kind of a waste of space, and the definition of "triplet" is vague, and in > >your example here, the word "linux" uselessly appears twice. > > We *have* had agreement on the triplet here: arm-linux-gnueabihf. it wasn't clear what triplet you were referring to. Debian's multiarch has its own concept (according to its own wiki), and then there's the GNU triplet. -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: Armhf dynamic linker path
On Wednesday 11 April 2012 11:25:55 Paulo César Pereira de Andrade wrote: > Probably beating a dead cow, but, the major problem with sysroots > would be the triplet name? > > E.g, in any architecture: > > /arm-linux-gnueabi/sysroot-contents-here it isn't really about having a sysroot the toolchain can find. that already works today for any target or multilib or isa or soft/hard float or arch or . the issue is having an ldso in its canonical path for runtime usage. i don't think anyone wants hardcoded tuple dirs in the root. some people can't even handle /bin or /sbin or /lib, so i'm afraid this proposal would cause them to implode ;). -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: Armhf dynamic linker path
On Wednesday 11 April 2012 03:37:56 Konstantinos Margaritis wrote: > On Tue, 10 Apr 2012 23:01:47 -0400 Mike Frysinger wrote: > > one of the downsides of traveling down a path and upstreaming as an after > > thought > > You didn't really follow arm hardfloat progress in the past 2 years, did > you (if you did you'd already be aware of attempts to get this thing > upstreamed for more than a year). i've only started following arm again as my last job (of 5+ years) was largely Blackfin related > Honestly, I'm curious, are you speaking your personal opinion or on behalf > of Gentoo? If the former then consider that we're trying to get consensus > amongst distros not people, it's impossible to make everyone happy, but > we'd be content to get distro people to agree on a standard. considering i did the Gentoo/ARM port ~8 years ago and maintain the toolchain on Gentoo for all arches, i have a fairly big incentive to keep things clean. > proposing it. So, I guess something like: > > /lib/ld-arm-linux-gnueabhif.so.3 > > or using the ABI name: > > /lib/ld-linux-aapcs-vfp.so.3 > > are the most likely candidates to be agreed by most distros, at least as I > see it. i can let the fine wording of the tuple in the filename be hammered out by others. if we don't care about multilib, then /lib/ is fine, and as long is it isn't crowed by subdir-cruft (i.e. /lib//), then i'm happy. side note: you really need to fix your mailer. the lack of proper wrapping is obnoxious. -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 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 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
