I have two gcc (same applies to g++) versions installed. The newer one is the default one:
/usr/bin/gcc # 4.9.2
/usr/bin/gcc-4.4 # 4.4.7
For my make command I want to use gcc-4.4 / g++-4.4.
I've tried these three variantes but none seems to work:
export CC="gcc-4.4"
export CPP="g++-4.4"
export CC=/usr/bin/gcc-4.4
export CPP=/usr/bin/g++-4.4
export gcc=/usr/bin/gcc-4.4
export g++=/usr/bin/g++-4.4
The Makefile defines:
# Compiler Options
CC = gcc
CPP = g++
LD = g++
The compiler used by the Makefile is still 4.9.2. How can I use 4.4.7?
GNU Make manual, 6.10 Variables from the Environment:
Variables in make can come from the environment in which make is run. Every environment variable that make sees when it starts up is transformed into a make variable with the same name and value. However, an explicit assignment in the makefile, or with a command argument, overrides the environment. (If the -e flag is specified, then values from the environment override assignments in the makefile. But this is not recommended practice.)
The recommended practice is to pass these variables on make command line:
$ make CC=gcc-4.4 CPP=g++-4.4 CXX=g++-4.4 LD=g++-4.4
A side note is that CXX is used for compiling C++ code, whereas CPP is for preprocessing. Either the author of the makefile confused CPP with CXX, or the makefile indeed uses CPP for generating dependencies, which has been unnecessary for the last decade or so. See this for more details.
Related
I'm working with a third-party-modified version of clang 7.0.0 that has hijacked the -c option, replacing it with a flag -ccdsp for... reasons...
This has created two problems for CMake:
The -ccdsp option seems to be required to be the very first option to clang, before anything else, including -D... and -I... parameters. There is a BEFORE modifier for target_compile_options that I can use to make sure it appears at the start of the option list, but I don't seem to have any control over the ordering of non-options like definitions and include-paths, which results in -ccdsp occurring later in the overall set of parameters. I haven't been able to find a way to ensure that this is the very first option using modern CMake methods. Instead I have had to resort to setting CMAKE_CXX_FLAGS explicitly.
Now that the -c option to specify a source file is no longer available, I need to find a way to get CMake to omit it. It turns out that, as far as I can tell, this flag isn't really required, as clang -c foo.cpp -o foo.o and clang foo.cpp -o foo.o appear to do much the same thing. So I need a way to get CMake to drop the -c option.
I realise that this is an unusual question and it's a situation entirely created by the organisation that provided the modified version of clang. Unfortunately my support requests to them remain (to date) unanswered.
Does anyone know of a way I can work around this issue? Can I create a custom compiler handler in CMake, based on clang, where I add -ccdsp and remove -c somehow?
In CMake a compiler's command line is specified in CMAKE_<LANG>_COMPILE_OBJECT variable.
You may set this variable in a separate file:
my_clang_override.cmake:
set(CMAKE_CXX_COMPILE_OBJECT "<CMAKE_CXX_COMPILER> -ccdsp <FLAGS> -o <OBJECT>")
and include this file into the project's CMakeLists.txt by specifying CMAKE_USER_MAKE_RULES_OVERRIDE variable with either of two ways:
Specify the variable in the CMakeLists.txt itself, before the project() call:
CMakeLists.txt:
# Assume file 'my_clang_override.cmake' to be in the project's source directory.
set(CMAKE_USER_MAKE_RULES_OVERRIDE "my_clang_override.cmake")
Pass the variable's setting to cmake when configure the project:
cmake -DCMAKE_USER_MAKE_RULES_OVERRIDE=<path/to/my_clang_override.cmake> <other-parameters>
I am trying to compile a fortran code with gnu-autotools. The openmp specific lines in configure.ac is:
AC_PROG_FC([gfortran])
AC_OPENMP
FCFLAGS="$OPENMP_FCFLAGS -fcheck=all"
If I compile with this, I am not getting omp related compiler options, as described in the AC_OPENMP macro in autoconf manual.
If I explicitly place -fopenmp in place of $OPENMP_FFLAGS, only then its working.
Any help please?
Autoconf typically likes testing everything for C language by default and that's why you're only getting $OPENMP_CFLAGS as a result for the AC_OPENMP command. However, Autoconf also provides mechanisms to change the programming language (and therefore the compiler also) by using the AC_LANG command (please, take a look at Autoconf / Language Choice webpage for further details and also some alternatives).
The following code has been tested using the command autoconf 2.69 and using the command: autoreconf -fiv (also using an empty Makefile.am file).
AC_INIT([omp-fortran-sample], [1.0])
AC_PROG_CC
AC_PROG_FC([gfortran])
dnl Checks for OpenMP flag for C language, stores it in $OPENMP_CFLAGS
AC_LANG(C)
AC_OPENMP
dnl Checks for OpenMP flag for Fortran language, stores it in $OPENMP_FCFLAGS
AC_LANG(Fortran)
AC_OPENMP
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
The resulting execution of the configure shows two tests for OpenMP as seen here:
checking for gcc option to support OpenMP... -fopenmp
checking for gfortran option to support OpenMP... -fopenmp
And Makefile now includes both OPENMP_CFLAGS and OPENMP_FCFLAGS definitions, among the rest, as shown below:
...
MKDIR_P = /bin/mkdir -p
OBJEXT = o
OPENMP_CFLAGS = -fopenmp
OPENMP_FCFLAGS = -fopenmp
PACKAGE = omp-fortran-sample
...
I have a custom compiled gcc 5.4.0 with the following folder structure /home/gccprefix/lib64/libstdc++.so.6.
So far compiling has been going well passing extra flags via configure such as CC=/home/gccprfix/bin/gcc CFLAGS=-fPIC CFLAGS=-Wfatal-errors CFLAGS=-I/home/gccprefix/header/tr1.
But now I have it a problem compiling cairo with /home/gccprefix/bin/ragel. To compile I have a bash script with the flags allocated as a variable, such as
MYFLAGS="CC=/home/gccprfix/bin/gcc CFLAGS=-fPIC CFLAGS=-Wfatal-errors CFLAGS=-I/home/gccprefix/header/tr1"
.../configure ${MYFLAGS}
Ragel was compiled with the /home/gccprefix/bin/gcc as above with no errors.
However during make for cairo, I get
ragel: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by ragel)
This is due to gcc finding the default /usr/lib64/libstdc++.so.6. So following several threads on SO I believe I need to extend the flags passed to configure.
What is the correct syntax
`CFLAGS=-Wl,-rpath,/home/gccprefix/lib64`
or do I drop the CFLAGS=
`-Wl,-rpath,/home/gccprefix/lib64`
Using the first option with CFLAGS= the new libstdc++.so.6 is not passed and the same error occurs, using the send without a CFLAGS just gives an error
configure: error: unrecognized option: `--Wl,-rpath,/home/gccprefix/lib64'
So what prefix do I use?
The correct syntax would be
./configure ... LDFLAGS=-Wl,-rpath=/home/gccprefix/lib64
Looking at the generated Makefiles, you could probably get away with CXXFLAGS but not with CFLAGS which are not used at all for a C++-only project.
Note CFLAGS=-fPIC CFLAGS=-Wfatal-errors CFLAGS=-I... is pointless, only -I... will be passed to the compiler, and only to a C compiler. Try CXXFLAGS="-fPIC -Wfatal-errors -I..." instead, making sure configure gets that as a single argument. Passing it via MYFLAGS probably won't work.
In my Makefile I have
CC=g++
When I do mgrep gcc, I have several versions listed like:
gnu/gcc/4.2.1
gnu/gcc/4.7.3
etc
I can do a module load to change my gcc version.
Now suppose I want to use multiple versions simultaneously in different makefiles, how do I do it?
The module system is basically just setting up a path to the requested module. If you want a particular compiler in a particular makefile, then you can do three things:
Expect the user of the makefile to load the correct version before calling Make. Possibly combined with some condition based on gcc -v|grep ${GCC_VERSION} to check that it's the right version.
Perform module load gnu/gcc/${GCC_VERSION} inside your makefile.
Use CC=/somewhere/path-to-gcc-version/bin/g++ instead of CC=g++.
Personally, I prefer 1 or 3. You can find out what the path is by doing module load ... and then which g++.
[By the way, I would use CXX=g++ and CC=gcc - assuming you are not compiling files called *.c as C++-code]
With Mac OS X 10.6 Apple changed the default target of g++ so it produces 64-bit rather than 32-bit code. I know I can specify "-arch i386" on the command line but is there any way to globally change the default architecture by means of an environment variable or similar? (I keep getting linking errors because I'm having real problems finding all the places I need to specify the architecture on the project I'm porting.)
Not that I know of. Depending on the configuration & build system you’re using, setting the CXXFLAGS, CFLAGS, and LDFLAGS environmental variables to include -arch i386 can help. However, some configuration & build system are tricky and it might not be sufficient to set those variables.
Another option is to provide a g++ (and friends as needed) bash script in a PATH location that precedes /usr/bin and invokes the actual command with -arch i386 along with the command-line arguments passed to the script.
An alternative to the solution described in the previous paragraph is to use arch(1) in one of its various forms. For instance, the shell script described above could invoke arch -i386 /usr/bin/g++. You can also set the ARCHPREFERENCE environmental variable to something like g++:/usr/bin/g++:i386,x86_64 and invoke arch /usr/bin/g++. However, note that you must use arch to invoke /usr/bin/g++.
Option 1
You could set your path so that it searches your private bin directory first.
In this bin directory place a g++ script that explicitly invokes the correct g++ compiler will the appropriate flags.
Option 2
Set a g++ alias. This will then be used in preference to a command. Set the alias to run the command with the appropriate flags.
Note: Both of these assume you are building from the command line as XCode probably explicitly executes the g++ binary.