Re: [PATCH] Fix -print-multi-os-directory for aarch64

[Marcus Shawcroft <marcus.shawcroft@gmail.com>]

On 8 March 2013 09:32, Jakub Jelinek <jakub@redhat.com> wrote:
> On Fri, Mar 08, 2013 at 09:04:19AM +0000, Marcus Shawcroft wrote:
>> On 07/03/13 16:45, Jakub Jelinek wrote:
>> >On Thu, Mar 07, 2013 at 08:29:06AM -0800, Andrew Pinski wrote:
>> >>On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek <jakub@redhat.com> wrote:
>> >>>AFAIK aarch64 libraries are supposed to go into /usr/lib64 etc.
>> >>>directories similarly to x86-64 etc., but as aarch64 isn't a true
>> >>>multilib target (having two different backends for 32-bit vs. 64-bit code),
>> >>>currently gcc -print-multi-os-directory prints . instead of ../lib64.
>> >>
>> >>I think glibc is broken also. So after this change, the build using
>> >>the released 2.17 and this new gcc breaks.
>> >
>> >Then glibc will need patching too.  Distros using multiarch aren't affected
>> >by this, others IMHO will want it in */lib64 and for aarch64 IMHO it isn't
>> >still too late for that change.
>>
>> Hi, Moving from /lib to /lib64 will affect binutils 2.23 (ld) and
>> glibc 2.17.  This seems to me to be a rather disruptive change this
>> late in the day.
>
> Yes, it does affect them, on the binutils side it would be about
> setting LIBPATH_SUFFIX=64 in ld/emulparams/aarch64linux.sh when appropriate
> (grep LIBPATH_SUFFIX=64 ld/emulparams/*.sh to see what other targets do),
> on the glibc side for other targets sysdeps/gnu/configure.in
> is where libc_cv_slibdir and libc_cv_libdir are tweaked.
> Note, this change doesn't affect multiarch, so Debian/Ubuntu is unaffected,
> for others there can be an easy workaround for transitional period
> (just add */lib64 -> */lib symlinks (or vice versa)).
> The point of using */lib64 is that it is consistent with how most other
> important 64-bit architectures are handled (x86_64, ppc64, s390x, sparc64,
> mips64) and that even if you don't expect coexistence of 32-bit arm and
> 64-bit aarch64 libraries on the same filesystem right now, using */lib64
> allows that in the future.  Even if some distros use lib64 -> lib or vice
> versa symlinks for some time if they choose so, if there is agreement to go
> with lib64 path suffixes, it means packages that need to know this can be
> changed, rather than adding horrible hacks to see what library suffixes
> should be used.

My concern about the disruption associated with this change aside, I
agree that the change needs to happen in order to avoid long term
pain.  I see no objections on this thread or the related thread over
at glibc-ports, so go ahead and commit the patch.

/Marcus