| Message ID | 20130307111536.GA12913@tucnak.redhat.com |
|---|---|
| State | New |
| Headers | show |
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
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
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
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
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
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
--- 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.
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. Jakub