[steve.mcint...@linaro.org: Phone call (was Re: Armhf dynamic linker path)]
Getting bounces from this message. Let's try again. - Forwarded message from Steve McIntyre steve.mcint...@linaro.org - From: Steve McIntyre steve.mcint...@linaro.org Date: Wed, 11 Apr 2012 23:37:55 +0100 To: cross-dis...@lists.linaro.org Cc: Adam Conrad adcon...@debian.org, linaro-toolch...@lists.linaro.org, Jeff Law l...@redhat.com, libc-po...@sourceware.org, gcc-patches@gcc.gnu.org Subject: Phone call (was Re: Armhf dynamic linker path) X-attached: unknown 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. Phone numbers are listed in the wiki page above. I'll take notes and post minutes afterwards. Let's talk Friday and get this shaken out to a working conclusion. Thanks, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs - End forwarded message - Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
[steve.mcint...@linaro.org: Re: Armhf dynamic linker path]
Bugger, missed the thread fork and didn't send this invitation to everybody yet. - Forwarded message from Steve McIntyre steve.mcint...@linaro.org - Date: Wed, 11 Apr 2012 02:06:09 +0100 From: Steve McIntyre steve.mcint...@linaro.org To: Jon Masters j...@redhat.com Cc: cross-dis...@lists.linaro.org, Adam Conrad adcon...@debian.org, linaro-toolch...@lists.linaro.org, Jeff Law l...@redhat.com Subject: Re: Armhf dynamic linker path User-Agent: Mutt/1.5.20 (2009-06-14) On Tue, Apr 10, 2012 at 05:56:38PM -0400, Jon Masters wrote: Anyway. My proposal is that we all join the call that Steve is putting together on Thursday pm/eve, using my Red Hat bridge. He'll send out the information. I would very much appreciate it if you (Jeff) could join because you are widely known as a calming voice of reason and sanity (if only you scaled to the point we could have one of you on every call). I would also like it very much if anyone in the Fedora community who wants to share their input could also dial into that meeting. Let's have this out, get it finally nailed down, and move on. 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. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs ___ linaro-toolchain mailing list linaro-toolch...@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain - End forwarded message - Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Tue, Apr 10, 2012 at 09:32:22AM -0500, Dennis Gilmore wrote: On Tue, 10 Apr 2012 12:18:51 +0300 Konstantinos Margaritis konstantinos.margari...@linaro.org wrote: 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... 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. Aargh. Again, use of a standard triplet for arm hard-float was agreed by all parties at the Plumbers' meeting last September. For exactly this reason. Now it seems that a number of people have totally ignored that consensus for the last six months. 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. Precisely who in Redhat/Fedora land has the power to make decisions in this area? We've been clearly wasting our time thus far trying to negotiate agreements about the hard-float platform. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Wed, Apr 04, 2012 at 01:11:33AM +0200, Jakub Jelinek wrote: On Wed, Apr 04, 2012 at 09:18:59AM +1200, Michael Hope wrote: The subdirectories could be called fred and jim and it would still work. The only thing required is that this part of the naming scheme be agreed amongst the distros. This looks to me like it's turning into a bike-shed painting excerise between the distros out there. That's really sad. I don't think we ever even had the discussion: Debian invented their Debian-internal scheme for managing multiple ABIs. They have in the past used patched versions of gcc, as in the case of x86_64. (cc'ed cross-distro as the discussion is also going on there[1]. This patch continues that) I like the idea of incompatible binaries having different loaders. The path doesn't matter but the concept does. Like i686/x86_64, it gives distros the option to install different binaries alongside each other for compatibility, performance, or upgrade reasons. The compatibility cost is nice and low and lets Debian do some interesting cross development things. Does the dynamic linker itself contain any routines that depend on the soft/hard ABI? That would quite surprise me, so I don't see the point of having different dynamic linkers for those ABIs. One dynamic linker should handle both just fine. That's been discussed previously, yes. While technically quite feasible in terms of code, there's enough potential for confusion that we though it was just simpler to use two different linker binaries. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Wed, Apr 04, 2012 at 01:34:30PM +1200, Michael Hope wrote: 2012/4/4 Paulo César Pereira de Andrade I did two ports of Mandriva to armv7. One of my choice to use softfp, and another hardfp port to be compatible with other distros. But other than a previous armv5 port, there is not much else of Mandriva arm, so, it would be good to have to be able to run binaries for either without resorting to a chroot, and only testing purposes. Bumping major or calling it ld-linux-foo.so.3 is out of question? I suspect /lib/ld-linux-$foo.so.3 would be fine. There's two questions here though: can the hard float loader have a different path and, if so, what should it be? We're still working on the first part. We've previously discussed changing the name or the version number of the linker, but there was a worry that compatibility would be broken. Apparently the Meego folks have released a hard-float system using ld-linux.so.3 and were concerned about this. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, Apr 05, 2012 at 11:32:39AM +1200, Michael Hope wrote: So: * Big endian: undefined, defaults to /lib/ld-linux.so.3 * Little endian, soft float: /lib/ld-linux.so.3 * Little endian, hard float: /libhf/ld-linux.so.3 Standard upstream practice supports having multiple variants that plausibly run on the same system at the same time, such as /lib and /lib64, and it seems reasonable to support hard and soft float variants that way via a directory such as /libhf. The Debian-style paths are not the default on any other architecture and I don't think it's appropriate to make them the default for this particular case only. OK. Debian multiarch covers libraries and headers but not executables. As a MIPS hard float /usr/bin/ls would collide with an ARM hard float /usr/bin/ls then it's fine for the loader names to potentially collide as well. In practice they wouldn't as most architecture has a subtily different loader name (cf. ld.so.1 for MIPS, ld-linux.so.2 for i386, and ld-linux.so.3 for ARM). Yes, thankfully. More by luck than any design. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, Apr 05, 2012 at 01:16:27PM +1200, Michael Hope wrote: On 5 April 2012 12:07, Joseph S. Myers jos...@codesourcery.com wrote: No. A system is either purely hard-float or purely soft-float, and the same paths are used for both so they can't coexist. (Mismatches at *static* link time are detected through object attributes.) Ah, the same as ARM then. The MIPS community would need something similar to this patch if they wanted to support soft and hard float side by side. Yes, definitely. Big endian is extremely uncommon on ARM and I'd rather define it when needed. For strictness sake I'll change the patch to use the new path for hard float little endian only. I don't think that's correct; the new path should be used independent of endian, just as the existing path is. OK. But any multiarch support patch should presumably define separate multiarch paths for each endianness. That's up to Debian. I've asked for documentation on the final tuples and what they mean as the one at: http://wiki.debian.org/Multiarch/Tuples is out of date. I prefer defining what is needed now and doing others as needed. I'm most of the way through an update for that page now; I'll ask for comments/review shortly. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote: On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote: On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore 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 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) 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. 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). 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. Except you wouldn't - the Debian/Ubuntu plan with multi-arch is to put them all in cleanly-separated paths corresponding to the triplets. I'm concerned that the potential proliferation of /lib* directories here could become very messy over time. I'm surprised that people seem to be happy to invent another namespace on a much more ad-hoc and arbitrary basis than the (mostly) well-understood triplets that we already have defined in the toolchains. Multi-arch is an attempt to make things cleaner for those of us that care about having lots of different platforms supported in parallel. Seen against that background, I was hoping that using the multi-arch path for the armhf linker would make sense. For people that don't care about multi-arch for themselves, a simple symbolic link is all that's needed. Cheers, -- Steve McIntyresteve.mcint...@linaro.org http://www.linaro.org/ Linaro.org | Open source software for ARM SoCs
