| Message ID | 03fb27de-b533-a17f-257d-7720029e9503@codesourcery.com |
|---|---|
| State | New |
| Headers | show |
| Series | [build] Unbreak objc build | expand |
Hi Tobias, > When I tried to bootstrap with --enable-languages=default, which includes > objc, it failed to build libobj. care to describe exactly how the build fails? > PS: Assuming the build was indeed broken for everyone since 2 years, maybe > one should remove 'objc' from the 'default' languages? – Which languages is > now nowadays supposed to use when bootstrapping? I usually have > 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto' > which is implied by --enable-lto, which is default). There's certainly more to that failure than just --enable-languages=default: I'm regularly using --enable-languages=all,... (which includes objc) without any issues, on all of Solaris, Linux/x86_64, and Darwin. Rainer
Hi Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> wrote: >> When I tried to bootstrap with --enable-languages=default, which includes >> objc, it failed to build libobj. > > care to describe exactly how the build fails? > >> PS: Assuming the build was indeed broken for everyone since 2 years, maybe >> one should remove 'objc' from the 'default' languages? >> – Which languages is >> now nowadays supposed to use when bootstrapping? I usually have >> 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus >> 'lto' >> which is implied by --enable-lto, which is default). > > There's certainly more to that failure than just > --enable-languages=default: I'm regularly using > --enable-languages=all,... (which includes objc) without any issues, on > all of Solaris, Linux/x86_64, and Darwin Right, It’s not been broken at all AFAICT - I build it daily on Darwin (often several times) and frequently on Linux - as does anyone building —enable-languages=all see, for example https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html there must be some other explanation ;) cheers Iain >
On 11/26/19 8:13 PM, Iain Sandoe wrote: > Right, It’s not been broken at all AFAICT - I build it daily on Darwin > (often several times) and > frequently on Linux - as does anyone building —enable-languages=all Ideas are welcome. I first did: .../configure --prefix=/home/tburnus/projects/gcc-trunk --enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default --prefix=… make -j12 with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and automake-1.15.1 installed there. And that failed with: *** No rule to make target '…/libobjc/../cet.m4', needed by '…/libobjc/aclocal.m4'. Stop. Note the wrong path – the file is in ../libobjc/../config/cet.m4. Afterwards, I tried without --enable-maintainer-mode – and got exactly the same error. In any case, the directory in libobj/Makefile.in is wrong. Cheers, Tobias > see, for example > https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html > > there must be some other explanation ;) Suggestions? > cheers > Iain
Actually, can you both try with my patch applied? If it still builds for you and then builds for me, the problem is also solved. And with proper path it looks better in any case. (Remark: The compilation w/o maintainer mode was the usual Linux path, i.e. all under /usr/bin.) Tobias On 11/26/19 8:27 PM, Tobias Burnus wrote: > On 11/26/19 8:13 PM, Iain Sandoe wrote: > >> Right, It’s not been broken at all AFAICT - I build it daily on >> Darwin (often several times) and >> frequently on Linux - as does anyone building —enable-languages=all > > Ideas are welcome. I first did: > > .../configure --prefix=/home/tburnus/projects/gcc-trunk > --enable-maintainer-mode --enable-languages=c,c++,fortran,lto,default > --prefix=… > make -j12 > > with PATH=$pathToAutoTools/bin:$HOME with autoconf-2.69 and > automake-1.15.1 installed there. And that failed with: > > *** No rule to make target '…/libobjc/../cet.m4', needed by > '…/libobjc/aclocal.m4'. Stop. > > Note the wrong path – the file is in ../libobjc/../config/cet.m4. > > Afterwards, I tried without --enable-maintainer-mode – and got exactly > the same error. > > In any case, the directory in libobj/Makefile.in is wrong. > > Cheers, > > Tobias > >> see, for example >> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01480.html >> >> there must be some other explanation ;) > Suggestions? >> cheers >> Iain
On Tue, Nov 26, 2019 at 07:47:44PM +0100, Tobias Burnus wrote: > Build on x86-64-gnu-linux. > OK for the trunk? The patch is obvious. > PS: Assuming the build was indeed broken for everyone since 2 years, maybe > one should remove 'objc' from the 'default' languages? – Which languages is > now nowadays supposed to use when bootstrapping? I usually have > 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' (plus 'lto' > which is implied by --enable-lto, which is default). No, it isn't really broken unless --enable-maintainer-mode. aclocal_deps variable in libobjc/Makefile.in in which this bug is is only used in: $(srcdir)/aclocal.m4: @MAINT@ $(aclocal_deps) cd $(srcdir) && $(ACLOCAL) $(ACLOCAL_AMFLAGS) and when not --enable-maintainer-mode, @MAINT@ is replaced with # (otherwise with nothing). And many people test objc or obj-c++ daily or whenever they are bootstrapping. I do all my x86_64-linux bootstraps with --enable-languages=default,ada,obj-c++,lto,go,brig,d and i686-linux bootstraps with --enable-languages=default,obj-c++,lto,go,brig,d others are using =all etc. > libobjc/ > * Makefile.in (aclocal_deps): Fix path to cet.m4. > > diff --git a/libobjc/Makefile.in b/libobjc/Makefile.in > index d733fb2606b..f029880265e 100644 > --- a/libobjc/Makefile.in > +++ b/libobjc/Makefile.in > @@ -297,7 +297,7 @@ aclocal_deps = \ > $(srcdir)/../ltsugar.m4 \ > $(srcdir)/../ltversion.m4 \ > $(srcdir)/../lt~obsolete.m4 \ > - $(srcdir)/../cet.m4 \ > + $(srcdir)/../config/cet.m4 \ > $(srcdir)/acinclude.m4 > > $(srcdir)/configure: @MAINT@ configure.ac $(srcdir)/aclocal.m4 Jakub
On Tue, Nov 26, 2019 at 10:48 AM Tobias Burnus <tobias@codesourcery.com> wrote: > > When I tried to bootstrap with --enable-languages=default, which > includes objc, it failed to build libobj. > > As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file > is at a different location. I wonder why no one had the problem before > in the last years – the libobjc/Makefile.in change was r254904 on Nov > 17, 2017 (!). The config/cet.m4 file itself was also added on 2017-11-17 > in r254868. > > Doing some more archeology, the the Makefile.in was changed by the patch > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02314.html – and one sees > that libobjc/aclocal.m4 has /../config/cet.m4 while libobjc/Makefile.in > uses /../cet.m4.m4. – Actually, that's not the submitted version > (cet.m4.m4) – as the committed version has 'cet.m4'. Approval was: > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00641.html > > Build on x86-64-gnu-linux. > OK for the trunk? Yes. > > Tobias > > PS: Assuming the build was indeed broken for everyone since 2 years, > maybe one should remove 'objc' from the 'default' languages? – Which > languages is now nowadays supposed to use when bootstrapping? I usually > have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' > (plus 'lto' which is implied by --enable-lto, which is default). Though as mentioned, the problem only shows up with --enable-maintainer-mode which nobody uses as the requirements for automake/autoconfig is different through out of a combined tree. Thanks, Andrew Pinski >
On 11/26/19, Tobias Burnus <tobias@codesourcery.com> wrote: > When I tried to bootstrap with --enable-languages=default, which > includes objc, it failed to build libobj. > > As Rhy0lite on IRC correctly guessed, the issue is that the cet.m4 file > is at a different location. I wonder why no one had the problem before > in the last years – the libobjc/Makefile.in change was r254904 on Nov > 17, 2017 (!). The config/cet.m4 file itself was also added on 2017-11-17 > in r254868. I actually did have that problem; I just hacked around it by copying cet.m4 from config to its parent directory and then forgot about it... > > Doing some more archeology, the the Makefile.in was changed by the patch > https://gcc.gnu.org/ml/gcc-patches/2017-10/msg02314.html – and one sees > that libobjc/aclocal.m4 has /../config/cet.m4 while libobjc/Makefile.in > uses /../cet.m4.m4. – Actually, that's not the submitted version > (cet.m4.m4) – as the committed version has 'cet.m4'. Approval was: > https://gcc.gnu.org/ml/gcc-patches/2017-11/msg00641.html > > Build on x86-64-gnu-linux. > OK for the trunk? > > Tobias > > PS: Assuming the build was indeed broken for everyone since 2 years, > maybe one should remove 'objc' from the 'default' languages? – Which > languages is now nowadays supposed to use when bootstrapping? I usually > have 'c,c++,fortran,lto', 'default' seems to be 'c,c++,fortran,objc' > (plus 'lto' which is implied by --enable-lto, which is default). > >
libobjc/ * Makefile.in (aclocal_deps): Fix path to cet.m4. diff --git a/libobjc/Makefile.in b/libobjc/Makefile.in index d733fb2606b..f029880265e 100644 --- a/libobjc/Makefile.in +++ b/libobjc/Makefile.in @@ -297,7 +297,7 @@ aclocal_deps = \ $(srcdir)/../ltsugar.m4 \ $(srcdir)/../ltversion.m4 \ $(srcdir)/../lt~obsolete.m4 \ - $(srcdir)/../cet.m4 \ + $(srcdir)/../config/cet.m4 \ $(srcdir)/acinclude.m4 $(srcdir)/configure: @MAINT@ configure.ac $(srcdir)/aclocal.m4