Armhf dynamic linker path
dann.frazier at canonical.com
Tue Apr 3 01:05:43 UTC 2012
On Mon, Apr 02, 2012 at 07:56:16PM -0400, Mike Frysinger wrote:
> 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<riku.voipio at linaro.org> wrote:
> >>>> On 31 March 2012 19:52, Dennis Gilmore<dennis at gilmore.net.au> 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 .
> >>>> 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/<ldso> vs /lib/<multiarch>/<ldso> 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/<ldso> and multiarch peeps have to deal with that already, it'd
> make more sense to stick with /lib/<ldso>.
> 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" ?
The intent of this patch is to continue to use /lib/ld-linux.so.3[*] for
ARM EABI (aka "softfloat"/armel), but switch to
/lib/arm-linux-gnueabihf/ld-linux.so.3 for the hard float variant.
This allows for concurrent support of both ABIs on the same install.
/lib/ld-linux.so.2, as I understand it, is the legacy ABI (OABI). My
updated patch preserves this support.
[*] The /lib/ld-linux.so.3 bit isn't visible in my latest patch
because it is specified in a different file.
> > 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 ?
> cross-distro mailing list
> cross-distro at lists.linaro.org
More information about the linaro-toolchain