gcc47 @4.7.4_6, gcc48 @4.8.5_1 fails to build with newer texinfo

[posita (Matt Bogosian)]

main.log attached.

[posita (Matt Bogosian)]

main.log

[posita (Matt Bogosian)]

Apologies! Forgot to CC maintainer (mww@…), but I can no longer edit the ticket details.

[raimue (Rainer Müller)]

Appears to be an issue with texinfo:

:info:build /Users/matt/.site/var/macports/build/_Users_matt_.site_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/gcc-4.7.4/gcc/doc/gcc.texi:209: no matching `@end tex'
:info:build /Users/matt/.site/var/macports/build/_Users_matt_.site_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/gcc-4.7.4/gcc/doc/gcc.texi:209: no matching `@end multitable'
:info:build /Users/matt/.site/var/macports/build/_Users_matt_.site_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc47/gcc47/work/gcc-4.7.4/gcc/doc/gcc.texi:209: no matching `@end titlepage'
:info:build make[3]: *** [doc/gcc.info] Error 1

[posita (Matt Bogosian)]

For what it's worth, gcc47 is getting pulled in as a dependency of pdftk. Should I try (re)building texinfo and then try again?

[mpressman]

I was able to fix it by adding a '@' on line 89 and 91 so that @end tex becomes @@end tex

[mojca (Mojca Miklavec)]

Is this opportunistic usage of texinfo?

I would be curious if deactivating texinfo and then rebuilding gcc47 from source (sudo port -v -s destroot gcc47) helps because the packages have been built successfully on the build slaves.

[kencu (Ken)]

try downgrading to texinfo 6.1.0. Worked for me with gcc46.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53405.

I'll bet this affects other older versions of gcc too, not just gcc47.

[kencu (Ken)]

There was a patch idea I found at <​https://dev.openwrt.org/ticket/13039> that apparently worked for some, but it didn't seem to work when I briefly tried it. I might not have set the Env variable correctly. Downgrading texinfo fixed it, so I moved on.

diff --git a/toolchain/gcc/common.mk b/toolchain/gcc/common.mk
index c18a330..a8d7ca1 100644
--- a/toolchain/gcc/common.mk
+++ b/toolchain/gcc/common.mk
@@ -111,6 +111,7 @@ GCC_CONFIGURE:= \
                --build=$(GNU_HOST_NAME) \
                --host=$(GNU_HOST_NAME) \
                --target=$(REAL_GNU_TARGET_NAME) \
+               MAKEINFO=missing \
                --with-gnu-ld \
                --enable-target-optspace \
                --disable-libgomp \

[gthb (Gunnlaugur Thor Briem)]

I'll bet this affects other older versions of gcc too, not just gcc47.

It affects gcc48 too, with same log output. It does not affect gcc49; that one builds without problems for me. I have texinfo 6.3.

[kencu (Ken)]

Setting MAKEINFO=missing in the build environment on gcc46 does seem to get around this texinfo problem, even with the current texinfo installed. gcc takes forever to build so it's still running, but it's nicely skipping over the texinfo errors now and looks like it will finish (10.5 PPC / gcc46). I'll let you know about ultimate success, and as time goes by, I'll try the other gcc4.x versions to see if it works there too.

of course you now have to peg isl at the last version to build gcc46 -- ah well.

[kencu (Ken)]

Ah - no. The build of gcc46 ultimately fails waaay down the road when it tries to build libiberty and finds no makeinfo is available, and errors out. SO that fix would not appear to work, at least without further attentions.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #53667.

[herrmanthegerman (Dan Kå)]

Replying to kencu:

try downgrading to texinfo 6.1.0. Worked for me with gcc46.

That worked for me, too. As on my system texinfo 6.1.0 was still installed

$ port installed texinfo
The following ports are currently installed:
  texinfo @6.0_1
  texinfo @6.1_0
  texinfo @6.3_0 (active)

I just had to reactivate texinfo 6.1

# port activate texinfo @6.1
--->  Computing dependencies for texinfo
--->  Deactivating texinfo @6.3_0
--->  Cleaning texinfo
--->  Activating texinfo @6.1_0
--->  Cleaning texinfo

With that change, gcc47 @4.7.4 rebuilt and installed without issues.

[kencu (Ken)]

The attached patch patch-gcc46-texi.diff fixed the gcc46 build with texinfo 6.3 by repairing minor errors in ./gcc/doc/gcc.texi. It seems likely that something similar might fix the other gcc versions.

If anyone else might like to test it out on their systems please do so -- if it works we can incorporate that into the gcc46 patchfile set.

[kencu (Ken)]

the attached patch patch-gcc47-texi.diff fixes the gcc47 build with texinfo 6.3, similarly to the gcc46 patch.

[kencu (Ken)]

and finally, this patch patch-gcc48-texi.diff fixed gcc48. I suspect these are all essentially identical, but they were individually implemented and tested and there could possibly be minor differences.

[mf2k (Frank Schima)]

Has duplicate #53676.

[splaisan (Stephane Plaisance)]

thanks Ken but how do I use your patch? I tried 'port clean gcc48' and rerun the install command but did not work? Sorry but I am not used to hack into ports, just apply macport commands.

[kencu (Ken)]

​https://guide.macports.org/chunked/development.patches.html#development.patches.applying

[ballapete (Peter "Pete" Dyballa)]

Replying to splaisan:

thanks Ken but how do I use your patch? I tried 'port clean gcc48' and rerun the install command but did not work?

Can be simple…

port file <portname> will tell you the path to the port's Portfile. The directory with this file can have a files subdirectory. There you can save a copy of the patch files. Now edit Portfile with elevated privileges, i.e. sudo vi …. There can be a line starting with patchfiles-append. Here you can insert the names of the patch files, one only on each line. When it's more than one such file, you'll need to finish all but the last line with \.

Save a copy of Portfile somewhere. All your private additions will be remored when you next time invoke port selfupdate. Another thing is updating the value of revision. The patchfiles-append block can be added below the depends, before configuration is mentioned.

[kencu (Ken)]

Then you might still run into the new isl issue to deal with, however. I did this with the old isl still installed.

New issues are coming faster than we can fix the old ones :>

[kencu (Ken)]

Replying to splaisan:

thanks Ken but how do I use your patch?

if you look at the patch, by the way, it is a matter of just a few newlines in ./gcc/doc/gcc.texi. You could just as easily do it manually

cd `port work gcc48`
cd gcc*
cd gcc
cd doc
sudo vi gcc.texi -OR- bbedit gcc.texi -OR- whatever text editor you like

add your newlines as per the patch (10 seconds max)
save

cd /
sudo port -v upgrade (or install) gcc48 

and you're on your way -- if you don't run into the isl problem

[splaisan (Stephane Plaisance)]

new errors after patching '/gcc/doc/gcc.texi'

[splaisan (Stephane Plaisance)]

Thanks a lot for these detailed instructions. I could patch now but the build fails later on with multiples syntax errors (main_after-gcc48-patch.log). I guess I will have to live without gcc48 for a while...

[ballapete (Peter "Pete" Dyballa)]

Replying to splaisan:

I guess I will have to live without gcc48 for a while...

Why without? Did you uninstall the previous version? If not, then you still have its predecessor – and I think it could be 4.8.5_0…

[splaisan (Stephane Plaisance)]

I have 4.7 still Thanks for your efforts, I hope a fix will come soon for 4.8 in case some packages expect the newer version. Cheers

[kencu (Ken)]

Replying to splaisan:

Thanks a lot for these detailed instructions. I could patch now but the build fails later on with multiples syntax errors (main_after-gcc48-patch.log).

Well, that's the exact isl error I mentioned to you. You have to roll back isl to make this work right now. You probably still have the old isl on your system. Just activate the older version (like I have done)

port -v installed isl
The following ports are currently installed:
  isl @0.14.1_0+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-01-01T16:24:34-0800'
  isl @0.18_0+universal platform='darwin 10' archs='i386 x86_64' date='2017-03-01T22:13:14-0800'

then

sudo port activate isl @0.14.1_0+universal

then with the tiny mod I showed you, it should build (did for me two days ago).

[ewen-naos-nz (Ewen McNeill)]

I too had both these build problems (texinfo, isl), on OS X 10.11 (El Capitan) when some other upgrade forced gcc48 (and other gcc/llvm versions) to need to be rebuilt. However even after fixing both of them (adding .texi patch, reverting to older isl), with everything else updated, I still had further build errors on libgcc, of which the key lines seemed to be:

:info:build checking for suffix of object files... configure: error: in `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_gcc48/gcc48/work/build/x86_64-apple-darwin15/libgcc':
:info:build configure: error: cannot compute suffix of object files: cannot compile

and with some digging in ./build/x86_64-apple-darwin15/libgcc/config.log I found:

dyld: Library not loaded: /opt/local/lib/libisl.15.dylib
  Referenced from: /opt/local/lib/libcloog-isl.4.dylib
  Reason: image not found
xgcc: internal compiler error: Trace/BPT trap: 5 (program cc1)
libbacktrace could not find executable to open

which means that both isl and cloog (that had been built against the newer isl) will have to be reverted to finish the build. And if I do that port rev-upgrade wants to re-rebuild gcc49, and gcc5 again, to match those older isl and cloog again...

Since I didn't have a specific need for gcc48 -- it had just been dragged in by dependencies ages ago -- and it appeared nothing on my system depended on gcc48 specifically now, I ended up just uninstalling gcc48, and going back to the newer isl. gcc49 and gcc5, as well as multiple versions of llvm are plenty of compilers for my needs these days :-) (Plus I could do with the disk space back.)

Anyone specifically needing to build gcc48 at present probably needs the texi patch and activating older isl and activating older cloog. Otherwise gcc48 probably has to be updated to work with the newer isl.

Ewen

[kencu (Ken)]

I think cloog hasn't actually changed at all -- it looks like it just got rev-bumped to build against the newer isl. I suspect you could roll back isl and rebuild cloog and it would build against the older isl just fine.

I notice my installation of cloog is built against the older isl, so I must have rolled isl back before cloog was revbumped. No doubt though, when you start down this road, things can get confusing.

I was looking into how to install a parallel isl 1.14 version -- that in and of itself doesn't look too hard. Then gcc has to be able to be configured to build against a specified isl version, which is usually possible. And finally, I guess it doesn't matter if cloog is built against a different isl version than the one gcc is built against, so that might just be able to be ignored. Messy stuff, to be sure, but we have multiple installations of clang, llvm, gcc, lua, python, and others, so it's do-able.

Still, by far the neatest solution to this issue, if it works, would be to have a build version of isl that is used interally for the gcc build and then deleted after the build, as per 53662.

I'll see if I get time to make up some PRs for gcc46, 47, 48 I guess to get this texinfo issue off the table. Then we can close off this ticket and move on to fixing 53662.

[kencu (Ken)]

A fix for gcc48 is in ​https://github.com/macports/macports-ports/pull/375.

[ballapete (Peter "Pete" Dyballa)]

GCC48 built fine on Leopard, GCC47 still seems to have an issue with makeinfo/texinfo. After GTK3 will be built with GCC6 I'll try kencu's patch.

[kencu (Ken)]

thanks, Pete -- I deleted my PR as Marcus went another way with the fix. The alternative patch Marcus put through for gcc48 needs to be put to gcc47 and gcc46 as well. I'm sure he'll get to it eventually. Then they will need similar isl fixes, and you'll be good to go.

[Ionic (Mihai Moldovan)]

And libgcc45 and probably gcc43, gcc44, gcc45, gcc46...

[Ionic (Mihai Moldovan)]

I'll just call maintainer timeout on this one, particularly since the fix is a trivial backport of the patch we already have for gcc48.

Interestingly, some ports fail to build in trace mode while others don't. This is likely a consequence of opportunistic usage of texinfo (since the system version of texinfo on 10.9 is older than what we ship in MacPorts.)

It would probably be good to add a proper dependency on texinfo for all *gcc* ports, but meh, I don't care this much.

[Mihai Moldovan <ionic@…>]

In c794c0c2c823e65ac0271267a5149e858ea8bccc/macports-ports:

lang/{apple-gcc{0,2},gcc4{3,4,5,6,7}}: backport compilation fix with newer texinfo versions from f3ad20f63b0463.

Fixes: #53076