This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] ARM: Use different linker path for hardfloat ABI
Em 9 de abril de 2012 17:48, Adam Conrad <adconrad@debian.org> escreveu:
> On Thu, Apr 05, 2012 at 10:50:50AM +1200, Michael Hope wrote:
>> On 4 April 2012 18:54, Jakub Jelinek <jakub@redhat.com> wrote:
>> >
>> > If the agreement is that arm 32-bit softfp really needs to be installable
>> > alongside 32-bit hardfp (and alongside aarch64), then IMHO it should do it
>> > like all other multilib ports (x86_64/i?86/x32, s390/s390x, ppc/ppc64, the
>> > various MIPS variants) and what FSB says, e.g. use
>> > /lib/ld-linux.so.3 and */lib dirs for softfp,
>> > /libhf/ld-linux.so.3 and */libhf dirs for hardfp and
>> > /lib64/ld-linux.so.3 and */lib64 dirs for aarch64, have 32-bit
>> > arm-linux-gnueabi gcc configured for softfp/hardfp multilib with
>> > MULTILIB_OSDIRNAMES, etc., have it configured in glibc
>>
>> OK. ?This gives a different path for the hard float loader and lets
>> the Debian guys add on top of that. ?I'll ping them and see what they
>> think.
>
> The problem here that everyone !Debian isn't taking into account is that
> multilib paths don't solve our use-case. ?Multilib paths only solve the
> case of multiple ABIs on the same base processor family. ?As soon as you
> combine x86, arm, power, etc, you end up with overlaps (or, the potential
> for overlaps; the fact that various arches accidentally have different
> majors keeps those overlaps to a minimum right now, but that's not by
> design).
>
> Honestly, this is something we should have solved two decades ago, but the
> very idea that someone would want to do what Debian is now doing didn't
> occur to any of us. ?That's cool. ?We didn't think of it back then. ?That's
> no excuse to continue with the status quo just because it's the status quo.
>
> To be perfectly clear here, we don't care where the linker goes (really, we
> don't), we just want it to be both arch and ABI unique. ?If that means
> taking a crc32 of a rot-13 of the compiler flags used to define the ABI,
> and then stuffing the linker in /lib/gobbledygook/ld-linux.so, so be it.
>
> If this means setting up a (very) lightweight process with the LSB, where
> everytime a new distro proposes a shiny new arch/ABI, they submit it, and
> the LSB assigns them an ABI serial, and we all then agree to toss the
> linker in /lib/abi-00002345/ld-linux, that works too. ?Don't care. ?Really
> don't care.
>
> This isn't about trying to force people to switch from multilib to multi-
> arch, where the former is clearly working fine for them. ?It's not. ?This
> is purely about people bikeshedding about paths they consider un-pretty,
> while (I hope not maliciously or knowingly?) causing potential overlap and
> breakage for those of us for whom this actually matters and isn't purely
> a color selection exercise.
>
> In the short term, due to sheer luck, /libhf/ld-linux.so.3 would work for
> us, purely because that doesn't overlap with any other linkers that Debian
> currently ships. ?The fact that the multilib path happens to work doesn't
> make it correct for our use-case, and certainly doesn't make it correct
> ongoing.
>
> Ultimately, however, I want this solved. ?We thought we had this solved at
> Plumbers last fall. ?To hear now that we "didn't involve everyone" is
> disheartening, given that we ("we" being Debian and Ubuntu) were well
> outnumbered in that room by people from RedHat, Fedora, ChromeOS, and
> Gentoo. ?We all agreed on something back then, and now that I'm three
> weeks away from shipping an armhf distro, it's all exploded yet again into
> Bikeshed Part III: The Revenge of Purple Paint.
>
> I really want to ship a compiler than stuffs the "correct" and agreed
> upon linker in headers. ?I don't want to see third parties build binaries
> on Ubuntu that don't run on Fedora. ?No one wants to see that, I think.
>
> Obviously, conversely (though this is much less hassle), I need to be
> able to ship a linker symlink that matches expectations, so that binaries
> built on Fedora will run on Ubuntu. ?Again, I'm sure we all want that.
>
> So, pretty please, can we (A) address the concerns here without people
> putting up the "Unique paths are Debian trying to force multi-arch on us"
> straw man, and (B) agree to *something*, before I ship something that
> conforms to a standard agreed upon more than half a year ago that is now
> a cause for contention? ?Pretty please? ?With sugar on top? ?Kthx.
>
>> > (of course, aarch64 is going to be new, talking now about the 32-bit softfp vs. hardfp).
>>
>> Yip. ?I assume something like /lib64 to stay consistent with other
>> architectures. ?aarch64 is hard float only.
>
> I expect that most distros will probably ship their aarch64 libraries
> in /lib64 (Debian and Ubuntu won't, but that's fine) to keep consistent
> with their other 64-bit ports, but where you put libraries is entirely
> unrelated to where the linker lives. ?You could have all your libraries
> in /root/.trash/ and if the linker lives in a canonical location and
> can resolve that, that's fine. ?I will still (obviously, I think, from
> my comments above) argue that the linker should live in a guaranteed
> unique location. ?Overlap with other arches in /lib64 is certainly far
> more likely than overlap in /libhf.
Not trying to criticize, just attempt to show my view of the subject.
What I understand of Debian multiarch is the desire to be able to:
1. Mount the root directory from a file server in different computers.
1.1. Computers share user home directories, can see binaries of
other architectures, and can share "noarch" files, as that would
be a bug if such files were wordsize or byte order dependent.
2. Boot different kernels (linux, freebsd, etc) and be able to have
things just working. One kernel may even run binaries targeted
to the other as they are the same architecture, a U*X is a U*X,
or close enough.
Last time I looked at Debian wiki, there was not yet a defined
plan for bin/x-y-z/ paths, so, I understand this is an "incremental"
work in progress, and first goal is to install close enough binaries
together, e.g. run a X Server and drivers built for one ABI and client
applications built for another. Having firefox for one abi, and all
of gtk, and a myriad of loadable modules for another can be painful
to maintain... Applications that link to different ABI libGL looks like
a possible common case. Talking about lib*GL, I believe this is
one of the main reasons of hardfp arm, and only when passing
lots of float/double by value from different DSOs. Other reason is
that newer arm C compiler will support only software float or
hardware float with hardfp abi, but enough about it :-)
For the sake of a example, TeXLive ships mostly "noarch" files,
and pre built, statically linked binaries are installed in bin/dir with
"dir" being one of:
alpha-linux
amd64-freebsd
amd64-kfreebsd
i386-cygwin
i386-freebsd
i386-kfreebsd
i386-linux
i386-netbsd
i386-solaris
mips-irix
powerpc-aix
powerpc-linux
sparc-linux
sparc-solaris
universal-darwin
win32
x86_64-darwin
x86_64-linux
x86_64-solaris
> ... Adam Conrad
>
>
> _______________________________________________
> cross-distro mailing list
> cross-distro@lists.linaro.org
> http://lists.linaro.org/mailman/listinfo/cross-distro
Thanks,
Paulo