On 28/10/15 22:56, Riccardo Murri wrote:
Hello,
I am trying to build GCC 4.5 on my Ubuntu 15.04 laptop but cannot get it
to compile. As far as I got, there are two distinct errors, which
probably affect other old versions of GCC and other recent distros as well.
Why, oh why, would you need a GCC that old on a recent system?
You're bound to run into problems with that, since old GCC versions are
not aware of recent changes in the Linux distros...
But fine, you probably have a good reason to dive into this hellhole. :-)
I have a workaround for the first issue, but I have no clue about the
second.
(1) TexInfo 5.0 is more strict and rejects some `.texi` files as
invalid.
In the course of building GCC, the `.texi` files are compiled
using the (system-provided) `makeinfo` binary. However, GNU texinfo
5.0.0 (released Feb. 2013) apparently rejects some syntax that was
accepted by older versions of it, which causes the GCC building process
to fail::
if [ xinfo = xinfo ]; then \
makeinfo --split-size=5000000 --split-size=5000000
--split-size=5000000 --no-split -I ../../gcc/doc \
-I ../../gcc/doc/include -o doc/gccinstall.info
../../gcc/doc/install.texi; \
fi
../../gcc/doc/cppopts.texi:763: @itemx must follow @item
Makefile:4052: recipe for target 'doc/cpp.info' failed
make[3]: *** [doc/cpp.info] Error 1
Listing texinfo 4.13 as a dependency in the `.eb` file does not work; EB
reports ignoring dependencies when doing the initial build of GCC using
the "dummy" toolchain::
== 2015-10-25 21:02:55,510 main.Dummy INFO prepare: toolchain dummy mode,
dummy version; not loading dependencies
The only workaround I have found is to force *not* building the docs:
buildopts='MAKEINFO=missing'
Interesting, I think someone else on the list also ran into this
problem, and he resorted to actually patching GCC to fix the problem.
This looks like a cleaner solution (as long as you don't mind not having
the documentation at all).
Maybe the `EB_GCC` easyblock could be patched to add `MAKEINFO=missing`
in the initial steps, and only build documentation in the last step,
when it's actually useful? (and build dependencies are honored)
That sounds reasonable, but would that actually fix your problem?
If not, what's the big benefit in not building the docs in earlier
steps? Speed?
(2) Still, compilation of `libgcc` fails with some error I cannot
explain.
After working around the makeinfo issue, the build process fails with
this error::
# multilibs.
/dev/shm/GCC/4.5.3/dummy-dummy/gcc-4.5.3/obj/./gcc/xgcc
-B/dev/shm/GCC/4.5.3/dummy-dummy/gcc-4.5.3/obj/./gcc/
-B/home/rmurri/.local/easybuild/software/GCC/4.5.3/x86_64-unknown-linux-gnu/bin/
-B/home/rmurri/.local/easybuild/software/GCC/4.5.3/x86_64-unknown-linux-gnu/lib/
-isystem
/home/rmurri/.local/easybuild/software/GCC/4.5.3/x86_64-unknown-linux-gnu/include
-isystem
/home/rmurri/.local/easybuild/software/GCC/4.5.3/x86_64-unknown-linux-gnu/sys-include
-g -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem
./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED
-I. -I. -I../.././gcc -I../../../libgcc -I../../../libgcc/.
-I../../../libgcc/../gcc -I../../../libgcc/../include
-I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS
-DUSE_TLS -o _ashldi3.o -MT _ashldi3.o -MD -MP -MF _ashldi3.dep -DL_ashldi3 -c
../../../libgcc/../gcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
In file included from /usr/include/stdio.h:27:0,
from ../../../libgcc/../gcc/tsystem.h:87,
from ../../../libgcc/../gcc/libgcc2.c:29:
/usr/include/features.h:364:25: fatal error: sys/cdefs.h: No such file or
directory
compilation terminated.
Makefile:370: recipe for target '_ashldi3.o' failed
...
Makefile:21002: recipe for target 'bootstrap' failed
make: *** [bootstrap] Error 2
(at
easybuild/local/lib/python2.7/site-packages/easybuild/tools/run.py:360 in
parse_cmd_output)
I cannot understand this error, as the `sys/cdefs.h` file is regularly
present in `/usr/include`::
$ locate sys/cdefs.h
/usr/include/bsd/sys/cdefs.h
/usr/include/x86_64-linux-gnu/sys/cdefs.h
Any suggestions?
Maybe sys/cdefs.h moved, and GCC 4.5 isn't aware of that yet?
Have you tried something like:
CPATH=/usr/include/x86_64-linux-gnu:$CPATH eb GCC-4.5.3.eb ?
regards,
Kenneth
