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

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

[Jakub Jelinek]

Hi!

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.

The following patch fixes that.  As for --disable-multilib purposes
gcc.c does:
      /* When --disable-multilib was used but target defines
         MULTILIB_OSDIRNAMES, entries starting with .: (and not starting
         with .:: for multiarch configurations) are there just to find
         multilib_os_dir, so skip them from output.  */
      if (this_path[0] == '.' && this_path[1] == ':' && this_path[2] != ':')
        skip = 1;
we need to actually emit
static const char *const multilib_raw[] = {
". ;",
".:../lib64 ;",
NULL
};
for --disable-multiarch resp.
static const char *const multilib_raw[] = {
". ;",
".:../lib64:aarch64-linux-gnu ;",
NULL
};
for --enable-multiarch.  Tested (with cross compiler) configured with
--target aarch64-linux --enable-languages=c {,--disable-multilib} {,--enable-multarch}
(all 4 combinations) and output of all
./xgcc -B ./ --print-{multiarch,multi-lib,multi-directory,multi-os-directory}
looks good to me with it (i.e. as before the patch, except
--print-multi-so-directory prints ../lib64 instead of . previously.

Ok for trunk?

2013-03-07  Jakub Jelinek  <jakub@redhat.com>

	* config/aarch64/t-aarch64-linux (MULTARCH_DIRNAME): Remove.
	(MULTILIB_OSDIRNAMES): Set.
	* genmultilib: If defaultosdirname doesn't start with :: , set
	defaultosdirname2 instead, clear it and emit two . multilib_raw
	entries instead of just one.

--- gcc/config/aarch64/t-aarch64-linux.jj	2013-01-11 09:03:10.000000000 +0100
+++ gcc/config/aarch64/t-aarch64-linux	2013-03-07 11:23:07.602568188 +0100
@@ -22,4 +22,4 @@ LIB1ASMSRC   = aarch64/lib1funcs.asm
 LIB1ASMFUNCS = _aarch64_sync_cache_range
 
 AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be)
-MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu)
+MULTILIB_OSDIRNAMES = .=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)
--- gcc/genmultilib.jj	2013-01-13 13:23:38.000000000 +0100
+++ gcc/genmultilib	2013-03-07 11:35:22.881982721 +0100
@@ -267,6 +267,7 @@ fi
 # names.
 toosdirnames=
 defaultosdirname=
+defaultosdirname2=
 if [ -n "${multiarch}" ]; then
   defaultosdirname=::${multiarch}
 fi
@@ -280,6 +281,13 @@ if [ -n "${osdirnames}" ]; then
 	if [ -n "${multiarch}" ]; then
 	  defaultosdirname=${defaultosdirname}:${multiarch}
 	fi
+	case "$defaultosdirname" in
+	  ::*) ;;
+	  *)
+	    defaultosdirname2=${defaultosdirname}
+	    defaultosdirname=
+	    ;;
+	esac
 	shift
 	;;
       *=*)
@@ -352,6 +360,7 @@ for set in ${options}; do
 done
 optout=`echo ${optout} | sed -e 's/^ //'`
 echo "\".${defaultosdirname} ${optout};\","
+[ -n "${defaultosdirname2}" ] && echo "\".${defaultosdirname2} ${optout};\","
 
 # This part of code convert an option combination to
 # its corresponding directory names.

	Jakub

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

[Andrew Pinski]

On Thu, Mar 7, 2013 at 3:15 AM, Jakub Jelinek <jakub@redhat.com> wrote:
> Hi!
>
> 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.

Thanks,
Andrew


>
> The following patch fixes that.  As for --disable-multilib purposes
> gcc.c does:
>       /* When --disable-multilib was used but target defines
>          MULTILIB_OSDIRNAMES, entries starting with .: (and not starting
>          with .:: for multiarch configurations) are there just to find
>          multilib_os_dir, so skip them from output.  */
>       if (this_path[0] == '.' && this_path[1] == ':' && this_path[2] != ':')
>         skip = 1;
> we need to actually emit
> static const char *const multilib_raw[] = {
> ". ;",
> ".:../lib64 ;",
> NULL
> };
> for --disable-multiarch resp.
> static const char *const multilib_raw[] = {
> ". ;",
> ".:../lib64:aarch64-linux-gnu ;",
> NULL
> };
> for --enable-multiarch.  Tested (with cross compiler) configured with
> --target aarch64-linux --enable-languages=c {,--disable-multilib} {,--enable-multarch}
> (all 4 combinations) and output of all
> ./xgcc -B ./ --print-{multiarch,multi-lib,multi-directory,multi-os-directory}
> looks good to me with it (i.e. as before the patch, except
> --print-multi-so-directory prints ../lib64 instead of . previously.
>
> Ok for trunk?
>
> 2013-03-07  Jakub Jelinek  <jakub@redhat.com>
>
>         * config/aarch64/t-aarch64-linux (MULTARCH_DIRNAME): Remove.
>         (MULTILIB_OSDIRNAMES): Set.
>         * genmultilib: If defaultosdirname doesn't start with :: , set
>         defaultosdirname2 instead, clear it and emit two . multilib_raw
>         entries instead of just one.
>
> --- gcc/config/aarch64/t-aarch64-linux.jj       2013-01-11 09:03:10.000000000 +0100
> +++ gcc/config/aarch64/t-aarch64-linux  2013-03-07 11:23:07.602568188 +0100
> @@ -22,4 +22,4 @@ LIB1ASMSRC   = aarch64/lib1funcs.asm
>  LIB1ASMFUNCS = _aarch64_sync_cache_range
>
>  AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be)
> -MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu)
> +MULTILIB_OSDIRNAMES = .=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)
> --- gcc/genmultilib.jj  2013-01-13 13:23:38.000000000 +0100
> +++ gcc/genmultilib     2013-03-07 11:35:22.881982721 +0100
> @@ -267,6 +267,7 @@ fi
>  # names.
>  toosdirnames=
>  defaultosdirname=
> +defaultosdirname2=
>  if [ -n "${multiarch}" ]; then
>    defaultosdirname=::${multiarch}
>  fi
> @@ -280,6 +281,13 @@ if [ -n "${osdirnames}" ]; then
>         if [ -n "${multiarch}" ]; then
>           defaultosdirname=${defaultosdirname}:${multiarch}
>         fi
> +       case "$defaultosdirname" in
> +         ::*) ;;
> +         *)
> +           defaultosdirname2=${defaultosdirname}
> +           defaultosdirname=
> +           ;;
> +       esac
>         shift
>         ;;
>        *=*)
> @@ -352,6 +360,7 @@ for set in ${options}; do
>  done
>  optout=`echo ${optout} | sed -e 's/^ //'`
>  echo "\".${defaultosdirname} ${optout};\","
> +[ -n "${defaultosdirname2}" ] && echo "\".${defaultosdirname2} ${optout};\","
>
>  # This part of code convert an option combination to
>  # its corresponding directory names.
>
>         Jakub

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

[Jakub Jelinek]

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.

	Jakub

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

[Marcus Shawcroft]

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


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.

Cheers
/Marcus

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

[Jakub Jelinek]

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.

Because of disagreements (even when the psABI talked about lib64), we ended
up with hacks like:

MULTILIB_OSDIRNAMES = m64=../lib64$(call if_multiarch,:x86_64-linux-gnu)
MULTILIB_OSDIRNAMES+= m32=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)$(call if_multiarch,:i386-linux-gnu)
MULTILIB_OSDIRNAMES+= mx32=../libx32$(call if_multiarch,:x86_64-linux-gnux32)

on x86_64-linux, so if the decision on */lib vs. */lib64 on aarch64 is left
to everybody and there is no agreement, we'll need similar hacks for
config/aarch64/t-linux, something like
MULTIARCH_DIRNAME = $(if $(shell test -d $(SYSTEM_HEADER_DIR)/../../usr/lib64 -a ! -L $(SYSTEM_HEADER_DIR)/../../usr/lib64 && echo lib64),,$(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu))
MULTILIB_OSDIRNAMES = $(if $(shell test -d $(SYSTEM_HEADER_DIR)/../../usr/lib64 -a ! -L $(SYSTEM_HEADER_DIR)/../../usr/lib64 && echo lib64),.=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu))
(i.e. if /usr/lib64 is a directory and not a symlink, use ../lib64
multi-os-directory, otherwise . .  The issue is that all the effected
packages would need to contain similar hacks (gcc, binutils, glibc, libtool,
...).

	Jakub

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

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

/Marcus

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

[Matthias Klose]

[-- Attachment #1: Type: text/plain, Size: 3156 bytes --]

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


[-- Attachment #2: lib64.diff --]
[-- Type: text/x-diff, Size: 606 bytes --]

Index: gcc/config/aarch64/t-aarch64-linux
===================================================================
--- gcc/config/aarch64/t-aarch64-linux	(revision 196661)
+++ gcc/config/aarch64/t-aarch64-linux	(working copy)
@@ -22,4 +22,4 @@
 LIB1ASMFUNCS = _aarch64_sync_cache_range
 
 AARCH_BE = $(if $(findstring TARGET_BIG_ENDIAN_DEFAULT=1, $(tm_defines)),_be)
-MULTILIB_OSDIRNAMES = .=../lib64$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)
+MULTILIB_OSDIRNAMES = .=$(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib64),../lib64,../lib)$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu)

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

[Jakub Jelinek]

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

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

[Andrew Pinski]

On Thu, Mar 7, 2013 at 8:45 AM, Jakub Jelinek <jakub@redhat.com> 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.

My objection to moving to /lib64 was more to have both binutils and
glibc fixed.  I am happy now they are getting fixed.

Thanks,
Andrew