| Message ID | 52CFD42A.7030305@ubuntu.com |
|---|---|
| State | New |
| Headers | show |
ping, adding build maintainers 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 >
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 >> > >
--- 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; \