This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build
- From: Zhenqiang Chen <zhenqiang dot chen at linaro dot org>
- To: Matthias Klose <doko at ubuntu dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Yufeng Zhang <Yufeng dot Zhang at arm dot com>, Marcus Shawcroft <marcus dot shawcroft at arm dot com>
- Date: Fri, 10 Jan 2014 17:49:30 +0800
- Subject: Re: [PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build
- Authentication-results: sourceware.org; auth=none
- References: <CACgzC7Cv4=ZYh=fc9xGbabdyYGWfGqET2QAr8q0j7CERkhEv0A at mail dot gmail dot com> <52CFBC2F dot 9040004 at ubuntu dot com>
On 10 January 2014 17:23, Matthias Klose <doko@ubuntu.com> wrote:
> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
>> Hi,
>>
>> MULTIARCH_DIRNAME was removed @r196649 since the dir info had been
>> combined in MULTILIB_OSDIRNAMES.
>>
>> But MULTIARCH_DIRNAME was re-added @r201164. With this change, the
>> final multiarch_dir is combined as
>> "aarch64-linux-gnu:aarch64-linux-gnu", which is incorrect and leads to
>> multiarch build fail if the sysroot is in correct multiarch layout.
>>
>> Any reason to add MULTIARCH_DIRNAME? If it is not necessary, can we
>> remove it as the patch?
>
> see the thread "[patch] set MULTIARCH_DIRNAME for multilib architectures" from
> June 2013. I think it is necessary to have the default defined. Yesterday's
> build looks ok for me, looking at default and include paths, so maybe I don't
> yet understand the issue.
In our build, we configure eglbc with
rtlddir=/lib
libdir=/usr/lib/aarch64-linux-gnu
slibdir=/lib/aarch64-linux-gnu
And we configure gcc with "--disable-multilib --enable-multiarch",
But when building gcc libraries, configure FAIL since it can not find
the C libraries. And I try
./xgcc --print-multiarch
the output is "aarch64-linux-gnu:aarch64-linux-gnu"
Any comments?
Thanks!
-Zhenqiang
> I think aarch64 is the only architecture which introduces MULTILIB_* macros
> without actually building any multilib, just to set the default library name to
> lib64. So maybe this has some side effects.
>
> Matthias
>