This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] 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
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)