Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, 10 Apr 2012 07:36:07 +0200 Jakub Jelinek ja...@redhat.com wrote: We really want consistency about the dynamic linker names etc. across different targets and sneaking silently multiarch paths on one architecture would make it inconsistent with all the others. So, please just use /libhf/ld-linux.so.3. I personally find /libhf extremely ugly. If having a second path is a problem, how about using the triplet in the filename? Like: /lib/ld-linux-arm-linux-gnueabihf.so.3 ? Unique per arch and not multiarched. And AFAIK, Linux can handle long filenames just fine... Konstantinos
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, 10 Apr 2012 09:32:22 -0500 Dennis Gilmore den...@gilmore.net.au wrote: every distro uses a unique triplet, by putting the triplet in there you then need to get all distros to change to using the same triplets. I personally prefer /libhfp rather than /libhf but I am ok with using either. Any change from /lib would need us to do a mass rebuild. because while not 100% needed I would rather keep libraries with the linker. the changes to rpm to support it would be somewhat minimal. we have stated in Fedora though that we have no intention to support mixing hfp and sfp on the same system. we really do need to ensure consensus for arm64 which I think should be /lib64 for 64 bit arch consistency. Ok, I respect that, what about using the actual ABI name, ie aapcs-vfp? or something that includes both the architecture and the eabi, (arm-hardfloat, armhf, armhfp, etc), but *in* the filename (excluding the case of using a separate directory as it's not too popular). Also, I'm not suggesting changing the triplet or anything, just deciding on a unique name for the triplet. Debian's argument is that the default multilib solution is not future-proof and we would prefer something that is more unique. Regarding /lib64 for aarch64, that's an entirely different discussion, though I do agree it should be also be resolved sooner rather than later as well. Regards Konstantinos
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore den...@gilmore.net.au wrote: Fedora does use /lib64 on x86_64 I would personally prefer /libhfp but wouldn't object to /libhf though today we have f17 about to go beta and all of rawhide built using /lib Hi Dennis, One potential problem that is born from the /libhf suggestion is the danger of having a new top level directory (/libhf) with only one file, the dynamic linker. AFAIU it, no distro is currently willing to move away from its existing scheme (/lib), Debian is most likely not going to, at best there could be a symlink /libhf - /lib/triplet, but that is not solving the problem IMHO. What about other distros, if everyone is going to use a symlink for /libhf, then even suggesting it and relying on new top-level directories to solve the problem is the wrong approach. Loic suggested a -IMHO- better solution: to change the dynamic linker filename, not the dir, i.e. /lib/ld-linux-hf.so.3 (for this particular case). My 2c. -- Konstantinos Margaritis konstantinos.margari...@linaro.org
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger vap...@gentoo.org wrote: i don't think that's true. on an x86_64 system, the 64bit libs are in /lib64/. some distros tried to (pointlessly imo) resist and force 64bits into /lib/ when the native ABI was x86_64 (Gentoo included), but those are legacy imo, and afaik, they didn't break the ldso paths. so in a setup that only has hardfloat binaries, you'd have all the libs in /libhf/, not just the ldso. That's exactly my concern. If /libhf is chosen for the dymamic linker path, but it's not adopted by everyone else for libraries and other files, then at best you'd have a symlink, at worst a dir with only one file inside. the implication in supporting both hardfloat and softfloat simultaneously is that you'd could have them both installed. thus putting them both in /lib/ doesn't make much sense if you're still going to need /libhf/ to hold everything else. That case has only any chance of realization in a multiarch environment such as Debian/Ubuntu. The rest won't be affected at all. And the dynamic linkers -different filename of course- are the only libs that will be in /lib straight, the rest will be in /lib/triplet. So there is no danger of any conflict, at least not with libraries. -- Konstantinos Margaritis konstantinos.margari...@linaro.org
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger vap...@gentoo.org wrote: note: i don't care about /lib/ld-linux-hf.so.3 or /lib/ld-linux.so.4 or /libhf/ld-linux.so.[34]. /lib/triplet/ldso is really the only one i don't think doesn't belong. and I'm just saying that I dislike /libhf, I also think that just raising the version is a wrong solution. don't really know what you're talking about here. other distros have no problem with handling multilib. multilib for softfloat/hardfloat on arm? I don't think so, even for other arches -it was already demonstrated that you cannot e.g. have powerpc e500v2 and e600 installed concurrently, and anyway that's not the topic of the discussion here. Apart from multiarch there is no other solution to do that *for* arm, at least at the moment, because the two ABIs use exactly the same paths on a non-multiarch system. And I get back to the proposed solution /libhf -which is the multilib path you're referring to- and I'm saying that the topic here is for the linker path alone. In the hypothetical scenario that everyone agreed on /libhf for the linker path, but not for libraries -which would stay in /lib- , then we'd have a /libhf top directory with just one file, the linker. Or a symlink from /lib to /libhf or /lib/triplet to /libhf in Debian's case, but that defeats the purposes of having a new /libhf directory, doesn't it? I hope I was clearer now. -- Konstantinos Margaritis konstantinos.margari...@linaro.org
