* [PATCH] Fix -print-multi-os-directory for aarch64
@ 2013-03-07 11:15 Jakub Jelinek
2013-03-07 16:29 ` Andrew Pinski
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Jelinek @ 2013-03-07 11:15 UTC (permalink / raw)
To: Marcus Shawcroft, Paolo Bonzini, Alexandre Oliva, Matthias Klose
Cc: gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-07 11:15 [PATCH] Fix -print-multi-os-directory for aarch64 Jakub Jelinek
@ 2013-03-07 16:29 ` Andrew Pinski
2013-03-07 16:45 ` Jakub Jelinek
0 siblings, 1 reply; 9+ messages in thread
From: Andrew Pinski @ 2013-03-07 16:29 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Marcus Shawcroft, Paolo Bonzini, Alexandre Oliva, Matthias Klose,
gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-07 16:29 ` Andrew Pinski
@ 2013-03-07 16:45 ` Jakub Jelinek
2013-03-08 9:04 ` Marcus Shawcroft
2013-03-13 16:12 ` Andrew Pinski
0 siblings, 2 replies; 9+ messages in thread
From: Jakub Jelinek @ 2013-03-07 16:45 UTC (permalink / raw)
To: Andrew Pinski
Cc: Marcus Shawcroft, Paolo Bonzini, Alexandre Oliva, Matthias Klose,
gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-07 16:45 ` Jakub Jelinek
@ 2013-03-08 9:04 ` Marcus Shawcroft
2013-03-08 9:33 ` Jakub Jelinek
2013-03-13 16:12 ` Andrew Pinski
1 sibling, 1 reply; 9+ messages in thread
From: Marcus Shawcroft @ 2013-03-08 9:04 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Andrew Pinski, Paolo Bonzini, Alexandre Oliva, Matthias Klose,
gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-08 9:04 ` Marcus Shawcroft
@ 2013-03-08 9:33 ` Jakub Jelinek
2013-03-14 8:37 ` Marcus Shawcroft
0 siblings, 1 reply; 9+ messages in thread
From: Jakub Jelinek @ 2013-03-08 9:33 UTC (permalink / raw)
To: Marcus Shawcroft
Cc: Andrew Pinski, Paolo Bonzini, Alexandre Oliva, Matthias Klose,
gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-07 16:45 ` Jakub Jelinek
2013-03-08 9:04 ` Marcus Shawcroft
@ 2013-03-13 16:12 ` Andrew Pinski
1 sibling, 0 replies; 9+ messages in thread
From: Andrew Pinski @ 2013-03-13 16:12 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Marcus Shawcroft, Paolo Bonzini, Alexandre Oliva, Matthias Klose,
gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-08 9:33 ` Jakub Jelinek
@ 2013-03-14 8:37 ` Marcus Shawcroft
2013-03-14 18:07 ` Matthias Klose
0 siblings, 1 reply; 9+ messages in thread
From: Marcus Shawcroft @ 2013-03-14 8:37 UTC (permalink / raw)
To: Jakub Jelinek
Cc: Marcus Shawcroft, Andrew Pinski, Paolo Bonzini, Alexandre Oliva,
Matthias Klose, gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-14 8:37 ` Marcus Shawcroft
@ 2013-03-14 18:07 ` Matthias Klose
2013-03-14 18:26 ` Jakub Jelinek
0 siblings, 1 reply; 9+ messages in thread
From: Matthias Klose @ 2013-03-14 18:07 UTC (permalink / raw)
To: Marcus Shawcroft
Cc: Jakub Jelinek, Marcus Shawcroft, Andrew Pinski, Paolo Bonzini,
Alexandre Oliva, gcc-patches
[-- 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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH] Fix -print-multi-os-directory for aarch64
2013-03-14 18:07 ` Matthias Klose
@ 2013-03-14 18:26 ` Jakub Jelinek
0 siblings, 0 replies; 9+ messages in thread
From: Jakub Jelinek @ 2013-03-14 18:26 UTC (permalink / raw)
To: Matthias Klose
Cc: Marcus Shawcroft, Marcus Shawcroft, Andrew Pinski, Paolo Bonzini,
Alexandre Oliva, gcc-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2013-03-14 18:26 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-03-07 11:15 [PATCH] Fix -print-multi-os-directory for aarch64 Jakub Jelinek
2013-03-07 16:29 ` Andrew Pinski
2013-03-07 16:45 ` Jakub Jelinek
2013-03-08 9:04 ` Marcus Shawcroft
2013-03-08 9:33 ` Jakub Jelinek
2013-03-14 8:37 ` Marcus Shawcroft
2013-03-14 18:07 ` Matthias Klose
2013-03-14 18:26 ` Jakub Jelinek
2013-03-13 16:12 ` Andrew Pinski
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).