Cdtjkyj

I am working with Ubuntu 14.04 LTS.
This already ships a packaged gcc 4.8.4 but I wanted to have a later version of gcc.

Using the existing version 4.8.4, I built version 4.9.4 from the source code through the recommended chain compile-build-test-install.
I have used no exotic settings for ./configure except for a prefix directory and a program-suffix. The rest is default.
All seems to have gone well. The test summary for g++ shows no FAIL and two XPASS calls only

XPASS: g++.dg/tls/thread_local-order2.C -std=c++11 execution test

XPASS: g++.dg/tls/thread_local-order2.C -std=c++1y execution test

I then wanted to build version 5.4.0 using the newly installed 4.9.4, to put the latter to the test with a minimum learning curve.
I edited the same installation script used for 4.9.4 only by specifying the make flags CC and CXX.
These flags now point to the binaries in the 4.9.4 installation directory.

The configure stage for 5.4.0 proceeds well.
I see from the files config.log and Makefile that the new binaries' paths are read in correctly.

The build stage fails though and stderr reports some 100 errors.
The earliest and most frequently recurring ones are of type

`error: template with C linkage`

`error: template specialization with C linkage`

They show up in patterns of blocks like this one:

In file included from ${installation directory for 4.9.4}/include/c++/4.9.4/bits/stringfwd.h:40:0,

             from ${installation directory for 4.9.4}/include/c++/4.9.4/iosfwd:39,

             from /usr/include/x86_64-linux-gnu/gmp.h:25,

             from /usr/local/include/isl/val_gmp.h:4,

             from ${source directory for 5-4-0}/gcc/graphite-isl-ast-to-gimple.c:35:



${installation directory for 4.9.4}/include/c++/4.9.4/bits/memoryfwd.h:63:3: error: template with C linkage

   template<typename>

   ^

${installation directory for 4.9.4}/include/c++/4.9.4/bits/memoryfwd.h:66:3: error: template specialization with C linkage

   template<>

   ^

${installation directory for 4.9.4}/include/c++/4.9.4/bits/memoryfwd.h:70:3: error: template with C linkage

   template<typename, typename>

   ^

I would think that the 5.4.0 source is fine, since all information has been gathered and processed in the same way as it was for 4.9.4.
There could be an error/omission in the configure stage of either 4.9.4, or 5.4.0 or both.

Which flaws do these errors indicate? How do you fix them?

Thanks for thinking along.

A search query on StackExchange on error: template with C linkage gives about 171,000 results.
The posts that I skimmed do not seem to address this point:

https://stackoverflow.com/questions/29872494/compiling-a-program-under-windows-gives-a-bunch-of-error-template-with-c-linka

https://stackoverflow.com/questions/4115930/using-cygwin-to-build-template-with-c-linkage

Note that I am not interested in triaging the codes, but in setting up a (robustly) working compiler.

The problem has been avoided by setting the compilation switch --with-local-prefix=/usr of the configure shell script. The default is /usr/local, whereas Ubuntu appears to store the looked-for files in /usr. This has fixed the fatal errors in another compilation from source of HDF5 (see https://unix.stackexchange.com/a/346171/132913)

This setting is not recommended though. See the GCC on-line configure help:

--with-local-prefix=dirname

Specify the installation directory for local include files. The default is /usr/local. Specify this option if you want the compiler to search directory dirname/include for locally installed header files instead of /usr/local/include.

You should specify --with-local-prefix only if your site has a different convention (not /usr/local) for where to put site-specific files.

The default value for --with-local-prefix is /usr/local regardless of the value of --prefix. Specifying --prefix has no effect on which directory GCC searches for local header files. This may seem counterintuitive, but actually it is logical.

The purpose of --prefix is to specify where to install GCC. The local header files in /usr/local/include—if you put any in that directory—are not part of GCC. They are part of other programs—perhaps many others. (GCC installs its own header files in another directory which is based on the --prefix value.)

Both the local-prefix include directory and the GCC-prefix include directory are part of GCC’s “system include” directories. Although these two directories are not fixed, they need to be searched in the proper order for the correct processing of the include_next directive. The local-prefix include directory is searched before the GCC-prefix include directory. Another characteristic of system include directories is that pedantic warnings are turned off for headers in these directories.

Some autoconf macros add -I directory options to the compiler command line, to ensure that directories containing installed packages’ headers are searched. When directory is one of GCC’s system include directories, GCC will ignore the option so that system directories continue to be processed in the correct order. This may result in a search order different from what was specified but the directory will still be searched.

GCC automatically searches for ordinary libraries using GCC_EXEC_PREFIX. Thus, when the same installation prefix is used for both GCC and packages, GCC will automatically search for both headers and libraries. This provides a configuration that is easy to use. GCC behaves in a manner similar to that when it is installed as a system compiler in /usr.

Sites that need to install multiple versions of GCC may not want to use the above simple configuration. It is possible to use the --program-prefix, --program-suffix and --program-transform-name options to install multiple versions into a single directory, but it may be simpler to use different prefixes and the --with-local-prefix option to specify the location of the site-specific files for each version. It will then be necessary for users to specify explicitly the location of local site libraries (e.g., with LIBRARY_PATH).

The same value can be used for both --with-local-prefix and --prefix provided it is not /usr. This can be used to avoid the default search of /usr/local/include.

Do not specify /usr as the --with-local-prefix! The directory you use for --with-local-prefix must not contain any of the system’s standard header files. If it did contain them, certain programs would be miscompiled (including GNU Emacs, on certain targets), because this would override and nullify the header file corrections made by the fixincludes script.

Indications are that people who use this option use it based on mistaken ideas of what it is for. People use it as if it specified where to install part of GCC. Perhaps they make this assumption because installing GCC creates the directory.

I will address these inconsistencies in another post at my earliest opportunity.