[PATCH, AARCH64] MULTIARCH_DIRNAME breaks multiarch build
Fri Jan 10 11:06:00 GMT 2014
Am 10.01.2014 10:49, schrieb Zhenqiang Chen:
> On 10 January 2014 17:23, Matthias Klose <firstname.lastname@example.org> wrote:
>> Am 10.01.2014 09:23, schrieb Zhenqiang Chen:
>>> 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
> 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?
>> 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.
sorry, I have a local patch applied after the lib64 change, which I forgot to
* Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if
MULTILIB_OSDIRNAMES is not defined.
@@ -1837,7 +1837,7 @@
- "$(MULTIARCH_DIRNAME)" \
+ "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \
> tmp-mlib.h; \
applied/tested since July 2013 on the Debian/Ubuntu distro builds. It doesn't
affect the non-multiarch case.
Ok for the trunk?
More information about the Gcc-patches