On Tue, 3 Apr 2012, Michael Hope wrote:

+#define GLIBC_DYNAMIC_LINKER \

• "%{mhard-float:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
• %{mfloat-abi=hard:" GLIBC_DYNAMIC_LINKER_HARD_FLOAT "} \
• %{!mfloat-abi=hard:%{!mhard-float:" GLIBC_DYNAMIC_LINKER_SOFT_FLOAT "}}"

(a) -mhard-float is a .opt Alias for -mfloat-abi=hard so does not need to be handled in specs.

(b) You need to handle compilers configured with --with-float=hard, so make the specs depend on the default ABI the compiler was configured with.

(c) Please include libc-ports on future submissions and provide both the GCC patch and the glibc ports patch that have been tested to work together to build and install the library in the given path; a patch to one component like this cannot sensibly be considered in isolation. I imagine you'll need appropriate ARM preconfigure support to detect what ABI the compiler is using, much like the support for MIPS, so that the right shlib-versions files are used. I try to follow all ARM glibc discussions on libc-ports closely, as the ARM glibc maintainer; was there a previous discussion of the dynamic linker naming issue there that I missed? (The only previous relevant discussion that I recall is one on patches@eglibc.org starting at http://www.eglibc.org/archives/patches/msg01017.html, regarding how the dynamic linker should check that a library has the right ABI, and there was no real followup on that after I indicated what would seem to be the appropriate implementation approaches and places for subsequent discussion.)

I have no idea whether shlib-versions files naming a file in a subdirectory will work - but if not, you'd need to send a patch to libc-alpha to support dynamic linkers in subdirectories, with appropriate justification for why you are doing something different from all other architectures.

(d) Existing practice for Power Architecture and MIPS at least is that hard-float and soft-float *don't* use different library directories / dynamic linkers.

(e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that. So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think), and these different Debian-style names could be implemented separately in a multiarch patch if someone submits one that properly accounts for my review comments on previous patch versions (failure to produce such a fixed patch being why Debian multiarch directory support has not got into GCC so far).

On Wed, 4 Apr 2012, Michael Hope wrote:

The tricky one is new GCC with old GLIBC. GCC may have to do a configure time test and fall back to /lib/ld-linux.so.3 if the hard float loader is missing.

I don't think that's appropriate for ABI issues. If a different dynamic linker name is specified, GCC should use it unconditionally (and require new enough glibc or a glibc installation that was appropriately rearranged).

...

I have no idea whether shlib-versions files naming a file in a subdirectory will work - but if not, you'd need to send a patch to libc-alpha to support dynamic linkers in subdirectories, with appropriate justification for why you are doing something different from all other architectures.

Understood. For now this is just a path. There's more infrastructure work needed if the path includes a directory.

Formally it's just a path - but an important feature of GNU/Linux and the GNU toolchain is consistency between different architectures and existing upstream practice is that the dynamic linker is always in the same directory as the other associated libraries and that this has the form /lib<something>. In the absence of a compelling reason, which I have not seen stated, to do otherwise for a single case, I think that existing practice should be followed with the dynamic linker being in a directory such as /libhf.

The "more infrastructure work needed" makes clear that you need libc-alpha buy-in *before* putting any patches into GCC or ports. But maybe if you don't try to put the dynamic linker in a different directory from the other libraries, it's easier to support via existing mechanisms (setting slibdir differently if --enable-multiarch-directories or similar)?

Do the MIPS or PowerPC loaders detect the ABI and change the library path based on that? I couldn't tell from the code.

No, they don't detect the ABI. Both ABIs (and, for Power, the e500v1 and e500v2 variants - compatible with soft-float at the function-calling level but with some glibc ABI differences with soft-float and with each other) use the same directories.

...

(e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that.

Is this required, or should it be left to the distro to choose? Once the loader is in control then it can account for any distro specific features, which may be the standard /lib and /usr/lib for single ABI distros like Fedora or /usr/lib/$tuple for multiarch distros like Ubuntu and Debian.

I thought Fedora used the standard upstream /lib64 on x86_64 and so would naturally use a standard upstream /libhf where appropriate.

...

So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think)

I'd like to leave that discussion for now. The Debian goal is to support incompatible ABIs and, past that, incompatible architectures. libhf is ambiguous as you could have a MIPS hard float library installed on the same system as an ARM hard float library.

If you want both ARM and MIPS hard-float then I'd think you want both big-endian and little-endian ARM hard-float - but your patch defines the same dynamic linker name for both of those.

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.

...

and these different Debian-style names could be implemented separately in a multiarch patch if someone submits one that properly accounts for my review comments on previous patch versions (failure to produce such a fixed patch being why Debian multiarch directory support has not got into GCC so far).

Agreed. Note that this loader path discussion is unrelated to multiarch. It came from the same people so there's a family resemblance.

I think it's directly related, and that such a path is inappropriate by default; that ARM should be consistent with other architectures, and that if you want to support paths in such subdirectories that would be a separate multiarch patch series for GCC, binutils and glibc (but the PT_INTERP would still use /lib<whatever>/<name> without subdirectories in any case).

On Wed, 4 Apr 2012 07:09:46 -0500 Dennis Gilmore dennis@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.

However the triplet fedora uses is different to what debian uses so the location will be different. Which is a bigger issue. A generic upstream default is best.

On Thu, 5 Apr 2012 11:08:56 -0400 Mike Frysinger vapier@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.

On Thu, 5 Apr 2012 11:55:14 -0400 Mike Frysinger vapier@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.

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,

+++ Mike Frysinger [2012-04-05 13:37 -0400]:

On Thursday 05 April 2012 12:15:41 Steve McIntyre wrote:

...

On Thu, Apr 05, 2012 at 11:08:56AM -0400, Mike Frysinger wrote:

...

On Thursday 05 April 2012 09:30:23 Konstantinos Margaritis wrote:

...

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.

/lib/ and /libhf/ is just as "clean" as /lib/ and /lib64/ (and now /libx32/). i see no difference here with a gcc configured for these multilib paths.

Quite true, but that's viewing the world from a place where /lib /lib64 was the right answer. It's a very limited version of multiarch which only allows for the co-installability of 2 ABIs. /lib64 doesn't let us co-install arm64(aarch64) and amd64, for example (which is imminently going to be a very reasonable thing to want to do).

The limitation starts to show when you consider x32 and armhf so we get 4 top-level library names to deal with it: /lib /lib64 /libhf and /libx32, but that still only allows certain combinations of architectures/ABIs. The point about using the triplet(or something very similar) to distinguish things is that it is generic - any combination you care to mention will work.

Now you are right that it doesn't really matter for just the linker path. We can arrange to ensure that they don't clash in various ways, as discussed on this thread.

But there is a reasonable expectation that the linker lives in the same library directory as the other libraries, and we can only arrange for that to work if every architecture/ABI has it's own directory. Which is why using triplets (or something very similar) makes so much sense. Yes, it's a break with the /lib /lib64 convention, but it seems fairly clear to me that that is reaching the end of it's life and inventing this new top-level libfoo set that doesn't even solve the problem in the general case, isn't a good solution.

/lib/<triplet>/ was proposed for armhf and aarch64 in an attempt to get these architectures 'right' from the get-go, not to have to use symlinks.

It seems ironic if the outcome of the attempt to have a sensible namespace for these new ABIs from the start, is actually some other completely arbitrary namespace which is a much worse solution technically. I'm really surprised anyone would think that was a good choice, after thinking about the issue for a while.

I realise this way of thinking is a big break with recent tradition. I thought it was madness when I first came across it too, but if you step back and think about the wider problem for a while I hope you can see that this actually makes a great deal of sense.

Clearly those of us that have been thinking about this for some time have failed to include the glibc people in debates to date, and that is a massive cock-up, for which I apologise wholeheartedly. I don't really know how that happened, we really did spend quite a lot of time trying to be inclusive, because, well, that's the right thing to do. I guess it just shows how siloed distro development is, and thus why the cross-distro list is a very welcome development.

...

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.

the triplet situation isn't as clean as you imply here. there are already examples of not being able to tell the ABI based purely on that. mips64- linux-gnu could be n32 or n64. x86_64-linux-gnu could be x86_64 or x32.

Yes, but that's OK so long as those pairs are ABI-compatible, you can freely mix n32 and n64 mips libraries. If you can't do that for x86_64 and x32 libraries, but they have the same triplet, that seems like a bad plan.

the Debian multiarch project might have made up new triplets to account for this, but those don't translate exactly into the same triplet that are used for e.g. configure --host.

No, not exactly, which is why we originally had a similar-but-different set of tuples to describe the namespace, but after a lot of discussion and feedback decided that GNU triplets were good-enough, especially if we avoided incompatible use in the future, and thus avoided making up a new namespace (which has echoes of the discussion here).

...

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.

if you think that's a useful goal, then sure. but not everyone thinks the multiarch proposal is really all that useful. however, that (much larger) discussion is really out of scope here.

They are indeed two separate debates, but understanding why at least some of us think it's useful, and the point about a generic namesspace, does colour what might turn out to be sensible for linker paths from here on in. i.e making up two namespaces for related purposes needs to be carefully considered. Do we get somethig important in return for that, or do we just gratuitously complicate?

...

For people that don't care about multi-arch for themselves, a simple symbolic link is all that's needed.

i think it's safe to say that the wider community has yet to be convinced, so extending existing support via the existing standards makes more sense.

Except when the existing standard is so obviously limited, and we can't change it later because it gets baked into every ABI-compatible binary for evermore. The standard was invented when there were only ever two things that got co-installed and they were easily distinguished (32 and 64-bit x86). The world is more complicated than that now.

Wookey

+++ Mike Frysinger [2012-04-09 23:57 -0400]:

On Monday 09 April 2012 23:07:14 Wookey wrote:

...

/lib/<triplet>/ was proposed for armhf and aarch64 in an attempt to get these architectures 'right' from the get-go, not to have to use symlinks.

this logic really only makes sense if you're talking about multiarch.

No, it makes sense if want a generic scheme for avoiding linker path clashes evn if you choose not to use it for libraries too. Multilib (which you are all happy with) is just a less-generic version of the same thing.

many people still don't see the point in having many architectures installed simultaneously in a single system. it's a "problem" that doesn't really exist.

Agreed, but you do see the value in have _some_ installed at once. Why choose which ones will be useful in the future up-front? Make them all unique and you can do whatever turns out to be useful in the future. Just seems like good computer science to me.

...

...

the Debian multiarch project might have made up new triplets to account for this, but those don't translate exactly into the same triplet that are used for e.g. configure --host.

No, not exactly, which is why we originally had a similar-but-different set of tuples to describe the namespace, but after a lot of discussion and feedback decided that GNU triplets were good-enough, especially if we avoided incompatible use in the future, and thus avoided making up a new namespace (which has echoes of the discussion here).

that's not what the wiki says: http://wiki.debian.org/Multiarch/Tuples

(i'm not saying you're wrong, just that my only source of multiarch info is the aforementioned wiki)

Yes. That doc (when you wrote this) was out of date. It described a scheme we developed last year whjich was not the one finally used (after what you might call 'lengthy internal debate'). If you look now it's up to date. (and that version has been moved to http://wiki.debian.org/Multiarch/TuplesAbandoned).

Apologies for the confusion.

Of course now were using triplets fairly diretly we'll be hanging around insisting that triplets do indeed indicate unique ABIs henceforth. If that's not going to be considered reasonable upstream then the tuples scheme would need to be resurrected.

...

They are indeed two separate debates, but understanding why at least some of us think it's useful, and the point about a generic namesspace, does colour what might turn out to be sensible for linker paths from here on in. i.e making up two namespaces for related purposes needs to be carefully considered. Do we get somethig important in return for that, or do we just gratuitously complicate?

in this case, it comes back to a simple question: do we plan on supporting old abi and armhf simultaneously ?

You still don't get it do you? So long as you only look at each base arch and its ABI's independently we end up with this rather limitied naming scheme and inventing new linker paths on a 'what looks good enough today' basis.

Make a generic scheme and it works for all future arches and ABIs, without us having to argue about the triplet and the linker path separately.

Mind you, I read the 'case for multiarch' wiki page from your POV and I don't blame you being uninspired. It needs some work to get across to people why it's cool. I guess one thing that might seem usful to x86 people is that it makes crossgrading from a 32-bit system to a 64 bit system as simple as: (ensure both i386 and amd64 sources are avilable) dpkg --add-architecture amd64 (allow foreign arch) apt-get install dpkg:amd64 (change default arch) apt-get update; apt-get upgrade (upgrade everything to new arch)

That may or may not actually work bug-free today in Debian/Ubuntu, but if it doesn't it will very soon.

Similarly we can install all the cross-build dependencies for plymouth with: apt-get install -a armel build-dep -s plymouth The following packages will be REMOVED: apport gir1.2-glib-2.0 libgirepository-1.0-1 libncursesw5-dev python-gi The following NEW packages will be installed: gir1.2-atk-1.0:armel gir1.2-freedesktop:armel gir1.2-gdkpixbuf-2.0:armel gir1.2-glib-2.0:armel gir1.2-gtk-2.0:armel gir1.2-pango-1.0:armel libatk1.0-0:armel libatk1.0-dev:armel libavahi-client3:armel libavahi-common-data:armel libavahi-common3:armel libcairo-gobject2:armel libcairo-script-interpreter2:armel libcairo2:armel libcairo2-dev:armel libcomerr2:armel libcups2:armel libdatrie1:armel libdbus-1-3:armel libdbus-1-dev:armel libdrm-dev:armel libdrm-intel1:armel libdrm-nouveau1a:armel libdrm-radeon1:armel libdrm2:armel libgcrypt11:armel libgdk-pixbuf2.0-0:armel libgdk-pixbuf2.0-dev:armel libgirepository-1.0-1:armel libgnutls26:armel libgpg-error0:armel libgssapi-krb5-2:armel libgtk2.0-0:armel libgtk2.0-dev:armel libjasper1:armel libjpeg-turbo8:armel libjpeg8:armel libk5crypto3:armel libkeyutils1:armel libkms1:armel libkrb5-3:armel libkrb5support0:armel libncursesw5:armel libncursesw5-dev:armel libp11-kit0:armel libpango1.0-0:armel libpango1.0-dev:armel libpciaccess0:armel libtasn1-3:armel libthai0:armel libtiff4:armel libxcomposite-dev:armel libxcomposite1:armel libxcursor-dev:armel libxcursor1:armel libxdamage-dev:armel libxdamage1:armel libxext-dev:armel libxext6:armel libxfixes-dev:armel libxfixes3:armel libxft-dev:armel libxft2:armel libxi-dev:armel libxi6:armel libxinerama-dev:armel libxinerama1:armel libxrandr-dev:armel libxrandr2:armel x11proto-composite-dev x11proto-damage-dev x11proto-fixes-dev x11proto-randr-dev x11proto-xext-dev x11proto-xinerama-dev The following packages will be upgraded: libcomerr2 libgnutls-dev libgnutls-openssl27 libgnutls26 libgnutlsxx27

(Just to illustrate that it works for non-trivial cases).

Then cross-build it all with dpkg-buildpackage -aarmel

No messing about with chroots or sysroots or installing build-deps to funny paths required (although of course chroots and sysroots also still work, and are useful for lots of reasons).

It's the symmetry that the really nice thing.

Anyway, I digress rather now - I'll update the wiki page.

Wookey

On Thu, 5 Apr 2012, Michael Hope wrote:

...

I don't think that's appropriate for ABI issues.  If a different dynamic linker name is specified, GCC should use it unconditionally (and require new enough glibc or a glibc installation that was appropriately rearranged).

OK. I want GCC 4.7.1 to use the new path. Does this mean that released versions of GLIBC and GCC 4.7.1 will be incompatible, or does GLIBC pick the path up from GCC?

Released versions would be incompatible (you could make GCC check at configure time for too-old glibc if --with-float=hard); the path needs hardcoding in both places.

...

...

Do the MIPS or PowerPC loaders detect the ABI and change the library path based on that?  I couldn't tell from the code.

No, they don't detect the ABI.  Both ABIs (and, for Power, the e500v1 and e500v2 variants - compatible with soft-float at the function-calling level but with some glibc ABI differences with soft-float and with each other) use the same directories.

Sorry, I'm confused. I had a poke about with MIPS and it uses different argument registers for soft and hard float. Soft float uses $4 and hard float $f0. Are there shims or similar installed by the loader?

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.)

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. But any multiarch support patch should presumably define separate multiarch paths for each endianness.

On Thu, Apr 05, 2012 at 01:16:27PM +1200, Michael Hope wrote:

On 5 April 2012 12:07, Joseph S. Myers joseph@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,

On Tue, Apr 3, 2012 at 6:56 PM, Joseph S. Myers joseph@codesourcery.com wrote:

(e) Existing practice for cases that do use different dynamic linkers is to use a separate library directory, not just dynamic linker name, as in lib32 and lib64 for MIPS or libx32 for x32; it's certainly a lot easier to make two sets of libraries work in parallel if you have separate library directories like that.  So it would seem more appropriate to define a directory libhf for ARM (meaning you need a binutils patch as well to handle that directory, I think), and these different Debian-style names could be implemented separately in a multiarch patch if someone submits one that properly accounts for my review comments on previous patch versions (failure to produce such a fixed patch being why Debian multiarch directory support has not got into GCC so far).

The thread doesn't seem to be wrapping up, instead it appears to go in circles :-)

As a glibc maintainer, when it comes to this issue, I am guided by:

(1) This is a distribution problem and the solution needs to come from a consensus among the distributions.

(2) The gcc/glibc community should listen to the distributions.

The distributions have the most experience when it comes to whole-system issues. I certainly don't have that experience. Unfortunately *I* give the distributions a B- or C+ for communication. Please make it easy for me to give you an A. It is exceedingly difficult for me to review solutions that span multiple patches, emails, mailing lists, and communities. The best way to avoid rehashing old problems is to document the design and get sign off from the interested parties.

If I see uncoordinated and conflicting responses from the distributions... I get worried.

Is there a proposal on a wiki that begins to summarize the suggestions and solution?

Cheers, Carlos.