From: Steve McIntyre <steve.mcintyre@linaro.org>
To: Mike Frysinger <vapier@gentoo.org>
Cc: cross-distro@lists.linaro.org,
Richard Earnshaw <rearnsha@arm.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
libc-ports@sourceware.org,
"Joseph S. Myers" <joseph@codesourcery.com>
Subject: Re: [PATCH] ARM: Use different linker path for hardfloat ABI
Date: Thu, 05 Apr 2012 16:16:00 -0000 [thread overview]
Message-ID: <20120405161541.GX2880@linaro.org> (raw)
In-Reply-To: <201204051108.58683.vapier@gentoo.org>
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 McIntyre steve.mcintyre@linaro.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
next prev parent reply other threads:[~2012-04-05 16:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20120329193401.GA14860@dannf.org>
[not found] ` <4F75F2E2.3030909@arm.com>
[not found] ` <20120402210653.GC28152@dannf.org>
[not found] ` <CANLjY-nk7ML5QMBd0bKRJBA9stUOdvu1tWZqmFHxpRzObzFw1Q@mail.gmail.com>
2012-04-03 22:56 ` Joseph S. Myers
2012-04-04 2:40 ` Michael Hope
2012-04-04 9:06 ` Joseph S. Myers
2012-04-04 12:10 ` Dennis Gilmore
2012-04-05 13:30 ` Konstantinos Margaritis
2012-04-05 14:13 ` Niels de Vos
2012-04-05 15:08 ` Mike Frysinger
2012-04-05 15:24 ` Konstantinos Margaritis
2012-04-05 15:55 ` Mike Frysinger
2012-04-05 16:25 ` Konstantinos Margaritis
2012-04-10 4:10 ` Mike Frysinger
2012-04-05 16:16 ` Steve McIntyre [this message]
2012-04-05 17:36 ` Mike Frysinger
2012-04-04 23:33 ` Michael Hope
2012-04-05 0:07 ` Joseph S. Myers
2012-04-05 1:17 ` Michael Hope
2012-04-05 16:05 ` Steve McIntyre
2012-04-05 16:03 ` Steve McIntyre
2012-04-05 1:32 ` dann frazier
2012-04-05 14:57 ` Steve McIntyre
2012-04-10 20:31 ` Carlos O'Donell
[not found] <4F7AC2E1.6010000@redhat.com>
[not found] ` <4F7AD4CA.8010000@arm.com>
[not found] ` <20120403110140.GG16117@tyan-ft48-01.lab.bos.redhat.com>
[not found] ` <4F7B20D2.8060608@arm.com>
[not found] ` <4F7B227F.7060905@redhat.com>
[not found] ` <CANLjY-mDvnn8NcVQfYoUUGZD72GbH7mgYjxWOGOzLMiUwNyp2Q@mail.gmail.com>
[not found] ` <20120403231133.GI16117@tyan-ft48-01.lab.bos.redhat.com>
[not found] ` <CANLjY-=dGK05kzvHVkuo3o7p_iE1cxfTi0f+t-RMmGW+37WSEg@mail.gmail.com>
[not found] ` <CAHAq8pE48=eY77adiKz3PEBapXwkPn6rjr3viMoUKpJq4x-G_A@mail.gmail.com>
[not found] ` <CANLjY-k-sC86gmaTH+h-5o4_D2MOnQHB4ihhDhoPt1HbUzJp9w@mail.gmail.com>
[not found] ` <20120404065412.GJ16117@tyan-ft48-01.lab.bos.redhat.com>
2012-04-04 9:16 ` Joseph S. Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120405161541.GX2880@linaro.org \
--to=steve.mcintyre@linaro.org \
--cc=cross-distro@lists.linaro.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=libc-ports@sourceware.org \
--cc=rearnsha@arm.com \
--cc=vapier@gentoo.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).