| Message ID | CACgzC7Cv4=ZYh=fc9xGbabdyYGWfGqET2QAr8q0j7CERkhEv0A@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
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 >
On 31/01/14 12:37, Matthias Klose wrote: > ping, adding build maintainers > I was hoping one of the configury maintainers would comment on this. No such luck. Based on the following in the manual: "@code{MULTIARCH_DIRNAME} is not used for configurations that support both multilib and multiarch. In that case, multiarch names are encoded in @code{MULTILIB_OSDIRNAMES} instead." I think this is OK. Please give the configury maintainers 24 hours to comment before committing. R. > Am 10.01.2014 12:06, schrieb Matthias Klose: >> Am 10.01.2014 10:49, schrieb Zhenqiang Chen: >>> 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. >> >> sorry, I have a local patch applied after the lib64 change, which I forgot to >> forward. >> >> * Makefile.in (s-mlib): Only pass MULTIARCH_DIRNAME if >> MULTILIB_OSDIRNAMES is not defined. >> >> --- a/src/gcc/Makefile.in >> +++ b/src/gcc/Makefile.in >> @@ -1837,7 +1837,7 @@ >> "$(MULTILIB_EXCLUSIONS)" \ >> "$(MULTILIB_OSDIRNAMES)" \ >> "$(MULTILIB_REQUIRED)" \ >> - "$(MULTIARCH_DIRNAME)" \ >> + "$(if $(MULTILIB_OSDIRNAMES),,$(MULTIARCH_DIRNAME))" \ >> "$(MULTILIB_REUSE)" \ >> "@enable_multilib@" \ >> > 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? >> >> Matthias >> > >
diff --git a/gcc/config/aarch64/t-aarch64-linux b/gcc/config/aarch64/t-aarch64-linux index 147452b..77e33ea 100644 --- a/gcc/config/aarch64/t-aarch64-linux +++ b/gcc/config/aarch64/t-aarch64-linux @@ -23,7 +23,6 @@ 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) -MULTIARCH_DIRNAME = $(call if_multiarch,aarch64$(AARCH_BE)-linux-gnu) # Disable the multilib for linux-gnu targets for the time being; focus
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? Thanks! -Zhenqiang ChangeLog: 2014-01-10 Zhenqiang Chen <zhenqiang.chen@linaro.org> * config/aarch64/t-aarch64-linux (MULTIARCH_DIRNAME): Remove. # on the baremetal targets.