Gcc.hpp File Reference

Plans regarding installation of gcc. More...

Go to the source code of this file.

Detailed Description

Plans regarding installation of gcc.

Problems building 4.6.4
  • Generating pdf dblatex files...
    dblatex --dump --verbose --pdf -o /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.6.4_build/x86_64-unknown-linux-gnu/libstdc++-v3/doc/docbook/pdf/libstdc++-manual.pdf /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.6.4/libstdc++-v3/doc/xml/spine.xml
    Error: [Errno 2] No such file or directory
    File spine.xml exists, directory x86_64-unknown-linux-gnu/libstdc++-v3/doc/docbook/pdf/ also exists.
  • Already "dblatex spine.xml" in the same directory as the file yields that error! This can be corrected by installing "libxslt-tools" (Suse), which contains "xsltproc".
  • However then we get the same error as reported at http://www.mail-archive.com/texlive@linux.cz/msg00363.html .
  • This looks like a Linux-distribution problem; checking again with Suse 12.3 (currently Suse 12.2).
  • For now disabled target "pdf".
Incorrect .texi-files
  • In gcc.mak we have to copy the files copying-lib.texi, gpl.texi, due to syntax errors.
  • File gpl.texi was obtained from the internet, and additionally in line 291 we replaced "@header NO WARRANTY" by "@center NO WARRANTY".
  • Hopefully with a newer version of gcc this error goes away. </li
DONE (not reproducible, taken as caused by some strange state of the computer) Failure building gcc412/gcc due to internal compiler error
  • These problems arise on csltok when trying to install the new package 00140.
  • Building gcc412 fails:
    /home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2/gcc/config/i386/i386.md: In function ‘bypass_p’:
    /home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2/gcc/config/i386/i386.md:189:14: warning: comparison between ‘enum processor_type’ and ‘enum attr_cpu’
    /home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2/gcc/config/i386/i386.md:189:14: warning: comparison between ‘enum processor_type’ and ‘enum attr_cpu’
    ... repeated more than 8000 times
    gcc: Internal error: Killed (program cc1)
    Please submit a full bug report.
    See <http://bugs.opensuse.org/> for instructions.
    make[3]: *** [insn-attrtab.o] Error 1
  • Environment (csltok):
    kullmann-0:OKplatform> gcc --version
    gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
    Copyright (C) 2010 Free Software Foundation, Inc.
    This is free software; see the source for copying conditions.  There is NO
    kullmann-0:OKplatform> uname -a
    Linux csltok.swansea.ac.uk #1 SMP PREEMPT Sun Jul 31 02:04:11 BST 2011 x86_64 x86_64 x86_64 GNU/Linux
  • One should install gcc version 4.5.3 on that machine.
  • Another possibility would be to first install the local 4.5.3, and then using this compiler to install gcc412 --- this might actually be better, since it should be more likely that the newer build succeeds.
  • Building gcc on csltok however also fails! We get
    gcc -c  -g -fkeep-inline-functions -DIN_GCC   -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat -fno-common  -DHAVE_CONFIG_H -I. -I. -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc/. -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc/../include -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc/../libcpp/include -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3_build/./gmp -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gmp -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3_build/./mpfr -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/mpfr -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/mpc/src  -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc/../libdecnumber -I/home/kullmann/OKplatform/OKplatform/ExternalSources/builds/Gcc/gcc-4.5.3/gcc/../libdecnumber/bid -I../libdecnumber     insn-attrtab.c -o insn-attrtab.o
    gcc: Internal error: Killed (program cc1)
  • gcj is the GNU Compiler for Java, see http://gcc.gnu.org/java/ .
  • It supports:
    • Compilation of .java to bytecode (.class files).
    • Compilation of .java to linux executables and libraries.
    • Compilation of .class to linux executables and libraries.
  • See also "Supporting Java" in Buildsystem/ExternalSources/SpecialBuilds/plans/general.hpp.
  • gcj is part of the gcc package, and is built when calling "oklib gcc".
  • gcj, as built by "oklib gcc", doesn't compile .java files:
    • Consider the following Java file (HelloWorld.java):
      class HelloWorld {
        public static void main(final String[] argv) {
          System.out.println("Hello world!");
    • Compiling "HelloWorld.java":
      > $OKPLATFORM/ExternalSources/Installations/Gcc/4.5.3/bin/gcj HelloWorld.java -o HelloWorld --main=HelloWorld
      yields the following error message:
      gcj: error trying to exec 'ecj1': execvp: No such file or directory
    • The result should be to compile HelloWorld.java to a standalone executable:
      # Using system Gcj
      > gcj HelloWorld.java -o HelloWorld --main=HelloWorld
      > ./HelloWorld
      Hello world!
    • gcj, as of gcc-3.4, requires ecj to be downloaded before building; see "--with-ecj-jar" at http://gcc.gnu.org/install/configure.html and also in ExternalSources/builds/Gcc/gcc-4.5.3/INSTALL/configure.html:
          This option can be used to specify the location of an external jar file containing the Eclipse Java compiler. A specially modified version of this compiler is used by gcj to parse .java source files. If this option is given, the 'libjava' build will create and install an ecj1 executable which uses this jar file at runtime.
          If this option is not given, but an ecj.jar file is found in the topmost source tree at configure time, then the 'libgcj' build will create and install ecj1, and will also install the discovered ecj.jar into a suitable place in the install tree.
          If ecj1 is not installed, then the user will have to supply one on his path in order for gcj to properly parse .java source files. A suitable jar is available from ftp://sourceware.org/pub/java/.
    • The GCC source package includes a script "contrib/download_ecj" to download ecj. This could be called before calling ./configure in the GCC build process, which would result in GCJ being built with support for .java files.
    • ecj is the Eclipse Java compiler, and is under the Eclipse Public License. The difference in license is why ecj must be downloaded separately.
    • The difference in licensing raises the issue of whether we want to compile gcj with support for .java files.
Providing gcc 4.1.2
  • Special 412-targets:
    1. Programs needing gcc version 4.1.2 might also need the libraries, and so actually we might better keep the newly introduced 412-targets (which yet are flagged as "to be removed").
    2. These targets are boost412, bzip2412, gmp412.
    3. We should also add mpfr412, and mhash412 (once updated).
  • DONE Motivated by "GRASP cannot be compiled with gcc version 4.3" (see Buildsystem/ExternalSources/SpecialBuilds/plans/SAT.hpp), we should provide a permanent installation of version 4.1.2.
  • DONE Perhaps we should provide in general build-variables supporting usage of gcc (i.e., calling the compiler, and providing the instructions for fixing the shared libraries in the binaries.
  • DONE (see 'Putting "configure" under our version control') Changed configuration file sources/Gcc/configure-4.1.2.gz:
    1. On 18.6.2008 this changed file was introduced according to MG; ID 4494618f9a8b506adc41934941c81a7554e0c3f6.
    2. Documentation needs to be added by MG on these changes.
    3. If we compare it with the most recent gcc-4.1.2.tar.bz2 (with md5sum fad77c542b5f467255435ffbeed5ef51; this is the package as introduced by MG), then we get
      > diff configure gcc-4.1.2/configure
      <        | egrep 'texinfo[^0-9]*(4\.([4-9]|[1-9][0-9])|[5-9]|[1-9][0-9])' >/dev/null 2>&1; then
      >        | egrep 'texinfo[^0-9]*([1-3][0-9]|4\.[2-9]|[5-9])' >/dev/null 2>&1; then
      What is the meaning of these changes?
    4. From a certain version of texinfo (makeinfo etc) onwards, the precise format of the version number altered, and even though I had a new enough version of texinfo, without this patch, GCC will error during it's configuration step, complaining that I did not have a new enough version of texinfo. Applying the patch fixes this issue. See http://www.mail-archive.com/bug-binutils@gnu.org/msg04179.html and http://code.google.com/p/buildroot/source/browse/branches/john-avr32-buildroot/toolchain/binutils/2.18/100-makeinfo-version.patch?spec=svn705&r=705 .
  • DONE (see 'Putting "configure" under our version control') Gcc 4.1.2 will not link on some 64 bit systems
    • Gcc 4.1.2 assumes that 32 bit libraries are stored in /usr/lib /lib etc rather than /usr/lib32 /lib32 etc.
    • This is the case for most linux systems following the LSB (Linux Standard Base) conventions however debian-based distributions use the later convention. This results in the linker not finding the libraries during the building of gcc.
    • This has been fixed in later versions of gcc, and there is a patch available (MG: The patch works for me).
    • See http://www.trevorpounds.com/blog/?tag=ubuntu for details and a link to the patch.
    • An updated version of the GCC package with the patch applied is available at http://cs.swan.ac.uk/~csmg/gcc-4.1.2.tar.bz2 , and was generated by replacing gcc-4.1.2/gcc/config/i386/t-linux64 with the following file (called "t-linux64-new")
      # On x86-64 we do not need any exports for glibc for 64-bit libgcc_s,
      # override the settings
      # from t-slibgcc-elf-ver and t-linux
      SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver \
      # On Debian, Ubuntu and other derivitive distributions, the 32bit libraries
      # are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
      # /lib and /usr/lib, while other distributions install libraries into /lib64
      # and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
      # it doesn't tell anything about the 32bit libraries on those systems.  Set
      # MULTILIB_OSDIRNAMES according to what is found on the target.
      MULTILIB_OPTIONS = m64/m32
      MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
      LIBGCC = stmp-multilib
      INSTALL_LIBGCC = install-multilib
      EXTRA_MULTILIB_PARTS=crtbegin.o crtend.o crtbeginS.o crtendS.o \
      		     crtbeginT.o crtfastmath.o
      # The pushl in CTOR initialization interferes with frame pointer elimination.
      # crtend*.o cannot be compiled without -fno-asynchronous-unwind-tables,
      # because then __FRAME_END__ might not be the last thing in .eh_frame
      # section.
      CRTSTUFF_T_CFLAGS = -fno-omit-frame-pointer -fno-asynchronous-unwind-tables
      which has the following diff with the original
      > # On Debian, Ubuntu and other derivitive distributions, the 32bit libraries
      > # are found in /lib32 and /usr/lib32, /lib64 and /usr/lib64 are symlinks to
      > # /lib and /usr/lib, while other distributions install libraries into /lib64
      > # and /usr/lib64.  The LSB does not enforce the use of /lib64 and /usr/lib64,
      > # it doesn't tell anything about the 32bit libraries on those systems.  Set
      > # MULTILIB_OSDIRNAMES according to what is found on the target.
      < MULTILIB_DIRNAMES = 64 32
      < MULTILIB_OSDIRNAMES = ../lib64 ../lib
      > MULTILIB_DIRNAMES = 64 32
      > MULTILIB_OSDIRNAMES = ../lib64 $(if $(wildcard $(shell echo $(SYSTEM_HEADER_DIR))/../../usr/lib32),../lib32,../lib)
      One can see that the change allows the GCC build system to detect whether /lib is used for 64 bit libraries or 32 bit libraries
    • Therefore, assuming that the above file (t-linux64-new - md5sum = 0aae4a50588d97920b7f8ee96789550d ) is in the ExternalSources/sources/Gcc directory, and the original (pre-MG changes) gcc-4.1.2 tarball is called "gcc-4.1.2.tar.bz2" (md5sum a4a3eb15c96030906d8494959eeda23c) in the same directory, then we have the following procedure for generating the new gcc tarball:
      sources> mv gcc-4.1.2.tar.bz2 gcc-4.1.2.tar.bz2_ALT
      sources> tar jxvf gcc-4.1.2.tar.bz2_ALT
      sources> cp t-linux64-new gcc-4.1.2/gcc/config/i386/t-linux64
      sources> tar jcvf gcc-4.1.2.tar.bz2 gcc-4.1.2
      Note, the md5sum will not be the same as the original as the creation and modification time etc for t-linux64-new will be different.
    • Of course, the question is whether this patch is really a general improvement, and whether it creates problems with other systems?
    • Those who are interested in this patch need to test it on other systems.
    • And precise information on how to perform the improvements are needed (note that we are using already an altered gcc!).
  • We need information about gcc-4.1.2 in the installation page.
  • DONE (in the FAQ) We need also general information on why we need gcc-4.1.2 etc.
Install GCC 4.5.3 : DONE
  • DONE (building it, requiring zip) gcj
    1. Regarding gcj on csoberon we get the error
      checking for unzip... /usr/bin/unzip
      Illegal option: @
      Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point] [-C dir] files ...
      with configure for gcj. No zip is available on this machine, which perhaps makes the difference (on the other machines we have it). Looks like a gcc-bug; contacted the gcc mailing-list.
    2. For now we disable gcj (don't need it now).
    3. But we can simply add "zip" to the requirement.
  • DONE (we require zip) We need to install zip locally, and provide it to the gcc-build.
    1. Building it shouldn't be a problem.
    2. Gcc doesn't make provisions for that.
    3. So apparently one has to modify the path when installing gcc?
    4. Alternatively we could put it into OKplatform/bin.
    5. However this wouldn't solve the provision-problem, since (at least yet) we say that putting OKplatform/bin on PATH isn't required.
  • DONE (we require now also zlib, and use this) Build error on cs-oksvr:
    1. We get (for "oklib gcc")
      checking dynamic linker characteristics... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES.
      make[3]: *** [configure-stage1-zlib] Error 1
    2. It seems that is a bug in the gcc build (fixed hopefully in the next version).
    3. A proposal on the gcc mailing-list is to use --with-system-zlib.
    4. This can be done by
      ExternalSources> oklib gcc gcc_user_options_okl="--with-system-zlib"
  • We should also install these additional libraries "PPL" ("Parma Polyhedra Library") and "CLooG" for loop-optimisation.
DONE (gcc-building provided first a corrected version, which was then removed) texi2dvi (texinfo 1.13a) fails to build gcc.texi on some systems
  • Texinfo version 1.13a has a bug due to the formatting of strings passed to egrep.
  • This bug results in an error from texi2dvi during the gcc build process on systems using the en_GB.UTF-8 locale and versions of (e)grep >= 2.7.
  • This bug was first found to affect the OKlibrary in Dec 2010, and a corrected version of texi2dvi was made available on 22.8.2011.
  • DONE (correction applied in gcc-building) According to http://www.mail-archive.com/bug-texinfo@gnu.org/msg04519.html and the corresponding bug report, there is now a fix, and presumably this should be available in a new texinfo package soon on most systems.
  • DONE (we should avoid such hacks if possible, and here it is) One can run "LC_ALL=C oklib gcc" and the build completes without a problem.
  • DONE Request to specify which version of texi2dvi this was about; and also, for such issues dates need to be stated.
  • DONE (gcc-building provides now a corrected version) This is not a bug in the OKlibrary, but users should be aware of the issue.
DONE (no system-libraries needed anymore) Local Gmp/Mpfr are not used (appropriately)
  • The system-subdirectories of Gmp/Mpfr installation directories should not sit inside the directory with the gcc-version on the path --- the access to the system-version must be independent of the recommended gcc-version.
DONE (the internal build of Gmp+Mpfr does static linking; dynamic linking would be possible using the additional information from the gcc mailing list) How to use local Gmp + Mpfr?
  • Just using "--with-gmp" and "--with-mpfr" is not enough, but some linking information is needed --- only which?
  • Apparently LD_LIBRARY_PATH is to be used?
    checking whether the GNU Fortran compiler is working... no
    configure: error: GNU Fortran is not working; the most common reason for that is that you might have linked it to shared GMP and/or MPFR libraries, and not set LD_LIBRARY_PATH accordingly. If you suspect any other reason, please report a bug in http://gcc.gnu.org/bugzilla, attaching /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.2.4_build/x86_64-unknown-linux-gnu/libgfortran/config.log
  • However prefixing the configure-call by LD_LIBRARY_PATH="$(gmp_locsys_install_directory_okl)/lib:$(mpfr_locsys_install_directory_okl)/lib" has apparently no effect?
  • In gcc-4.2.4_build/x86_64-unknown-linux-gnu/libgfortran/config.log we find the usual f951-problem:
    /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.2.4_build/./gcc/f951: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
  • The library-file libmpfr.so.4 is in the Mpfr-lib-directory:
    kullmann-0:lib> pwd
    kullmann-0:lib> ls -l
    total 1256
    -rw-r--r-- 1 kullmann users 896598 2010-12-26 21:56 libmpfr.a
    -rwxr-xr-x 1 kullmann users   1165 2010-12-26 21:56 libmpfr.la
    lrwxrwxrwx 1 kullmann users     16 2010-12-26 21:56 libmpfr.so -> libmpfr.so.4.0.0
    lrwxrwxrwx 1 kullmann users     16 2010-12-26 21:56 libmpfr.so.4 -> libmpfr.so.4.0.0
    -rwxr-xr-x 1 kullmann users 381897 2010-12-26 21:56 libmpfr.so.4.0.0
    So apparently LD_LIBRARY_PATH is just ignored.
  • Tryin
    LDFLAGS="-L $(gmp_locsys_install_directory_okl)/lib -L $(mpfr_locsys_install_directory_okl)/lib"
    instead. But again this is just ignored.
  • Finally trying
    LDFLAGS="$(gmp_locsys_link_path_okl) $(mpfr_locsys_link_path_okl)"
    And again, this is just ignored. Exactly the same f951-error as above. The configure script continued with some reports, and contains the line "LDFLAGS=''", which seems a clear indication of a error in the build-script.
DONE (works now; problems were Gmp,Mpfr related) Local build of Fortran fails (for 4.1.2)
  • DONE (we don't build Fortran with 4.1.2) We get (for "oklib gcc") an error when building libgfortran:
    /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2/libgfortran/mk-kinds-h.sh: Unknown type
    grep '^#' < kinds.h > kinds.inc
    /bin/sh: kinds.h: No such file or directory
    make[3]: *** [kinds.inc] Error 1
    make[3]: Leaving directory `/home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2_build/x86_64-unknown-linux-gnu/libgfortran'
    make[2]: *** [all-target-libgfortran] Error 2
  • The error message "unknown type" is from the script libgfortran/mk-kinds-h.sh. This is an example of a bad error-message:
    1. There are two possible places for this output, without a possibility to distinguish them.
    2. They do not show the bad value (some size) under consideration.
  • Inserting output, it seems it comes from "case $largest_ctype", where apparently the value of largest_ctype is the empty string.
  • When compiling
    libgfortran> more tmp17093.f90
      real (kind=16) :: x
    one gets apparently an error (where there shouldn't be one):
    libgfortran> /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.1.2_build/./gcc/gfortran -c tmp17093.f90
    gfortran: error trying to exec 'f951': execvp: No such file or directory
    and thus largest_ctype is not re-set.
  • We get the same error on cs-wsok (Suse 10.0).
  • An Internet-search is needed: It seems that the build has linking problems with Mpfr (see http://lists.linuxtogo.org/pipermail/openembedded-issues/2007-November/006519.html ). There is other noise denying (as usual) any fault on the side of gcc, and blaming Gmp, recommending to use --host=none --target=none --build=none to disable platform-specific optimization (which wouldn't matter much here, since these libraries are only used at compile-time), however this doesn't seem likely here to me.
  • Let's try later gcc-versions --- perhaps the problem has been solved there (we could use later gcc-versions for Fortran (only)).
    1. DONE (actually this was only due to not using local Gmp/Mpfr; see above) Version 4.2.4 seems to install without problems (including gfortran).
    2. However yet we can't use it; see "Local installation of gfortran" in Buildsystem/ExternalSources/SpecialBuilds/plans/R.hpp.
    3. It is likely an R-build-problem, but we need to check.
  • The newest version 3.0.0 of Mpfr doesn't seem to make a difference.
  • Also without the library-settings for gmp-/mpfr we get the same error (on csltok; must have gone unnoticed before), so it seems it is not related to these additional settings.
  • DONE (everything is now built with the system-gcc) Perhaps a link-failure: Now we compile gfortran with 4.1.2, while the system-compiler is 4.5.0 --- perhaps building gfortran links to something compiled with 4.5.0 ?
  • DONE (we have now system-versions of gmp and mpfr) However it seems we need to build with (our) 4.1.2, since we need to use gmp and mpfr (which are build with (our) gcc 4.1.2.) ?
  • We need to find out what are the precise requirements when building gfortran (version 4.1.2).
  • DONE (handled now in this way) An alternative procedure would be to first build gcc-4.1.2 (only C and C++ compiler) with the system-compiler, building then gmp amd mpfr with the system-compiler as "system"-versions, and then building gfortran-4.1.2 (as well as the current full gcc-suite) with the system-compiler, using these gmp and mpfr.
  • Then for gmp,mpfr we would need three versions: the system-version, the 4.1.2-version, the current version. So well, seems appropriate.
  • DONE Then actually gmp and mpfr should be build first, and then all of gcc can be build at once --- no need to separate the fortran-build!
DONE (moved files into Programming/Specifics/Gcc/412) Putting "configure" under our version control
  • Since there are now various changes to various gcc-configuration files, we should put them under our version control.
  • Starting with the files in the original gcc-4.1.2-package.
  • It seems that the md5sum-value of the gcc-package is for the original package, then the new general configure-file was introduced, and then the special configuration-file as discussed below. (It seems these were the only changes.)
  • We handle it then as with for example Ubcsat: the package is the original, and during the build the new files are placed.
  • The appropriate place for the gcc-replacement files seems Programming/SystemSpecifics/Gcc.
  • At this time Programming/SystemSpecifics/plans/milestones.hpp should be updated.
  • The Externalsources/sources/gcc-4.1.2.tar.bz2 is now the original from the Gcc site with md5sum a4a3eb15c96030906d8494959eeda23c.
DONE (solved now --- with build 4.1.2 only for C,C++) GCC 4.1.2 will not build on systems without GMP with MPFR support
  • DONE (we built gmp and mpfr locally, and compile Fortran then; needs to be checked though) GCC 4.1.2 fails to build on some machines (notably the Swansea University Computer Science Linux lab machines), with the following error:
    checking whether the C compiler (gcc  ) is a cross-compiler... no
    checking whether we are using GNU C... yes
    checking whether gcc accepts -g... yes
    checking for gnatbind... gnatbind
    checking whether compiler driver understands Ada... no
    checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
    checking for correct version of gmp.h... yes
    checking for MPFR... no
    configure: error: GMP with MPFR support is required to build fortran
    make: *** [gcc] Error 1
    make: Leaving directory `/tmp/OKlib/OKplatform/ExternalSources'
  • DONE (at the moment we just have everything built with "our" gcc version 4.1.2; later we will have this and the builds with our newest version) Ideally we could just build GMP and MPFR as part of the OKlibrary build process, however, these libraries would then build using a newer version of GCC and we run the risk of there being incompatibilities with the version we are building when we start to compile anything in the library which might somehow link to standard libraries.
  • The GCC website (http://gcc.gnu.org/install/prerequisites.html) suggests it should be possible to simply drop GMP and MPFR source directories in the GCC source directory and build as normal :
    GNU Multiple Precision Library (GMP) version 4.3.2 (or later)
        Necessary to build GCC. If you do not have it installed in your library search path, you will have to configure with the --with-gmp configure option. See also --with-gmp-lib and --with-gmp-include. Alternatively, if a GMP source distribution is found in a subdirectory of your GCC sources named gmp, it will be built together with GCC.
    MPFR Library version 2.4.2 (or later)
        Necessary to build GCC. It can be downloaded from http://www.mpfr.org/. The --with-mpfr configure option should be used if your MPFR Library is not installed in your default library search path. See also --with-mpfr-lib and --with-mpfr-include. Alternatively, if a MPFR source distribution is found in a subdirectory of your GCC sources named mpfr, it will be built together with GCC.
  • However, building GCC with GMP and MPFR source directories "in-tree" (as such a method is called) with GCC 4.1.2 doesn't work yielding the same error.
  • Either additional configure options are needed, or GCC 4.1.2 doesn't support this. Perhaps such functionality has only been introduced in later GCC versions?
DONE (we go directly to 4.5.2, to minimise problems with additional libraries) Install GCC 4.2.4
  • First only as an alternative (since yet code doesn't compile with versions 4.2 or later).
  • Installation seems to work, however not for gfortran with local Gmp+Mpfr (see above).
DONE (we go directly to 4.5.2, to minimise problems with additional libraries) Install GCC 4.3.5
DONE (we go directly to 4.5.2, to minimise problems with additional libraries) Install GCC 4.4.5
  • DONE (we use 4.4.5, and we build local Gmp+Mpfr using system-gcc) Building 4.4.4:
    1. Now Gmp and Mpfr is needed.
    2. For Gmp just use the configure-option "--with-gmp=$(gmp_installation_dir_okl)".
    3. However, then we have the problem of a circular dependency, since these libraries are built using Gcc!
    4. The main question is about the link-library-compatabilities.
  • Building error (on csltok):
    1. We get
      ExternalSources> oklib gcc gcc_enable_languages_okl="c,c++,fortran" gcc_recommended_version_number_okl=4.4.5
      rm gcc.pod gfortran.pod
      make[4]: Leaving directory `/home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/gcc'
      mkdir -p -- x86_64-unknown-linux-gnu/libgcc
      Checking multilib configuration for libgcc...
      Configuring stage 2 in x86_64-unknown-linux-gnu/libgcc
      configure: creating cache ./config.cache
      checking for --enable-version-specific-runtime-libs... no
      checking for a BSD-compatible install... /usr/bin/install -c
      checking for gawk... gawk
      checking build system type... x86_64-unknown-linux-gnu
      checking host system type... x86_64-unknown-linux-gnu
      checking for x86_64-unknown-linux-gnu-ar... ar
      checking for x86_64-unknown-linux-gnu-lipo... lipo
      checking for x86_64-unknown-linux-gnu-nm... /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/./gcc/nm
      checking for x86_64-unknown-linux-gnu-ranlib... ranlib
      checking for x86_64-unknown-linux-gnu-strip... strip
      checking whether ln -s works... yes
      checking for x86_64-unknown-linux-gnu-gcc... /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/./gcc/xgcc -B/home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/./gcc/ -B/home/kullmann/OKplatform/ExternalSources/Installations/Gcc/4.4.5/x86_64-unknown-linux-gnu/bin/ -B/home/kullmann/OKplatform/ExternalSources/Installations/Gcc/4.4.5/x86_64-unknown-linux-gnu/lib/ -isystem /home/kullmann/OKplatform/ExternalSources/Installations/Gcc/4.4.5/x86_64-unknown-linux-gnu/include -isystem /home/kullmann/OKplatform/ExternalSources/Installations/Gcc/4.4.5/x86_64-unknown-linux-gnu/sys-include
      checking for suffix of object files... configure: error: in `/home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/x86_64-unknown-linux-gnu/libgcc':
      configure: error: cannot compute suffix of object files: cannot compile
      See `config.log' for more details.
      make[3]: *** [configure-stage2-target-libgcc] Error 1
    2. So here already with libgcc (not with libgfortran) we get an error??
    3. In gcc-4.4.5_build/x86_64-unknown-linux-gnu/libgcc/config.log we find
      /home/kullmann/OKplatform/ExternalSources/builds/Gcc/gcc-4.4.5_build/./gcc/cc1: error while loading shared libraries: libmpfr.so.4: cannot open shared object file: No such file or directory
      so, as usual, the linking-specifications are ignored. Later one finds (again) "LDFLAGS=''".
  • The installation-documentation doesn't say anything on this.
  • It seems that now also libraries "PPL" ("Parma Polyhedra Library") and "CLooG" are needed? Not needed, both are only for loop-optimisation.
  • Since we need the system-versions of Gmp and Mpfr apparently only for Gcc, we should try to put source-directories "gmp" and "mpfr" into the extracted gcc-source.
Installation in general
  • Documentation:
    1. Linking to the gcc-documentation (main info-page) should be checked for completeness.
    2. We could offer also to show the man-page (just open it into a browser); however then it should be said that likely the html-documentation is more complete.
    3. We should also move the info-pages to the doc-directory. How to view them? The least is just to open them into a browser.
  • DONE (not used anymore) If variable "gcc_version_okl" is set, then it should have one of the allowed values (while otherwise we get an error).
  • We must understand, how gcc interacts with 32- and 64-bit environments, and how to take control of this.
  • There should be make-variables, which allow control over some settings for the build of gcc.
  • texti2pdf is a script, which can be put into ~/bin for example, and is needed for building the gcc-documentation --- how to provide it? Such small utilities could be put under version control (OKlibrary) ?
  • Installation of R requires a Fortran compiler. Therefore the system-installation of Gcc should allow for enabling of Fortran language support.
  • DONE (yes, GMP and MPFR are installed locally) Enabling Fortran language support in Gcc requires that the MPFR and GMP libraries are installed. Should we install these also locally?
    1. GMP is also of interest to us regarding big-number-types, so we need full control about it, and perhaps a local installation is warranted (ignoring the system installation). UPDATE NEEDED
  • DONE (placed in Buildsystem/Configuration) Shouldn't file external_sources_versions.mak be placed in subdirectory Buildsystem/ExternalSources ?
  • DONE (it seems reasonable to remove the build-directory from the prerequisite-list and to build it "manually") If the filestamp does already exist, then we want nothing to happen --- however yet the build-directory will be rebuilt if not existent, since it is a prerequisite of the rule for the "tag-paths". So it seems necessary to remove the build-directory from the prerequisite-list, however then it seems impossible to create the build-directory, if actually gcc *is* to be build, via the target-mechanism.
  • DONE (now just "oklib gcc", and potentially setting gcc_recommended_version_number_okl) Instead of, e.g., "make gcc-4.1.2", wouldn't it be more consistent with building Boost to also have "make gcc gcc-version=4.1.2" ?

Definition in file Gcc.hpp.