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 <ja...@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
