Fix -print-multi-os-directory for aarch64

Am 14.03.2013 16:37, schrieb Marcus Shawcroft:
> 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.

sorry, didn't comment about this patch because it didn't seem to affect
multiarch.  However this patch assumes that every system does have at least a
*/lib64 symlink, if it doesn't have a */lib64 directory.  I think that is a
wrong assumption.  Things like

$ gcc --print-file-name libc.so
/usr/lib/gcc/aarch64-linux-gnu/4.8.0/../../../lib64/libc.so

would point to a non-existing path.

Attaching a patch which uses a check to only set this to ../lib64 if it does
exist, as done for other multilib configurations.

  Matthias

On Fri, Mar 15, 2013 at 02:07:12AM +0800, Matthias Klose wrote:
> sorry, didn't comment about this patch because it didn't seem to affect
> multiarch.  However this patch assumes that every system does have at least a
> */lib64 symlink, if it doesn't have a */lib64 directory.  I think that is a
> wrong assumption.  Things like

Why do you think the patch assumes it?  And why do you care for multiarch?
It just adjusts where the libraries are searched.

In a cross, I see (for non-multiarch):
grep '^  \$ \.\.' ../config.log; strace -v -s1024 ./xgcc -B ./ -print-file-name=libc.so 2>&1 | grep access.*libc.so
  $ ../configure --target aarch64-linux --enable-languages=c,c++
access("./aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("./libc.so", R_OK)               = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/../lib64/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/libc.so", R_OK) = -1 ENOENT (No such file or directory)

for multiarch:
grep '^  \$ \.\.' ../config.log; strace -v -s1024 ./xgcc -B ./ -print-file-name=libc.so 2>&1 | grep access.*libc.so
  $ ../configure --target aarch64-linux --enable-languages=c,c++ --enable-multiarch
access("./aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("./aarch64-linux-gnu/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("./libc.so", R_OK)               = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux-gnu/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux/4.8.0/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/aarch64-linux-gnu/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/../lib64/libc.so", R_OK) = -1 ENOENT (No such file or directory)
access("/usr/src/gcc/objaa2/gcc/../lib/gcc/aarch64-linux/4.8.0/../../../../aarch64-linux/lib/libc.so", R_OK) = -1 ENOENT (No such file or directory)

as you can see, if lib64 paths don't exist, it just goes on to look in */lib (like it does on x86_64 etc).
And, for multiarch, it looks first in multiarch directories.

Checking for lib64 directory or symlink is what I'd prefer to avoid.

	Jakub