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
...
Related
I am trying to compile tensorflow with a custom clang/llvm toolchain and using clang's native libc++ (instead of borrowing Gcc's stdlibc++).
It looks like bazel plain assumes that every clang will use Gcc's libraries because I get these errors:
$ bazel build --cxxopt=-std=c++11 --cxxopt=-stdlib=libc++ tensorflow:libtensorflow.so
INFO: Found 1 target...
INFO: From Compiling
external/protobuf/src/google/protobuf/compiler/js/embed.cc [for host]:
external/protobuf/src/google/protobuf/compiler/js/embed.cc:37:12:
warning: unused variable 'output_file' [-Wunused-const-variable]
const char output_file[] = "well_known_types_embed.cc";
^
1 warning generated.
ERROR: /home/hbucher/.cache/bazel/_bazel_hbucher/ad427c7fddd5b68de5e1cfaa7cd8c8cc/external/com_googlesource_code_re2/BUILD:11:1: undeclared inclusion(s) in rule '#com_googlesource_code_re2//:re2':
this rule is missing dependency declarations for the following files included by 'external/com_googlesource_code_re2/re2/bitstate.cc':
'/home/hbucher/install/include/c++/v1/stddef.h'
'/home/hbucher/install/include/c++/v1/__config'
I tried to hack into tools/cpp/CROSSTOOL inside bazel as some posts suggested to add the line
cxx_builtin_include_directory: "/home/hbucher/install/include/c++/v1"
but to no avail, it does not seem to make any difference.
Then I tried to follow a bazel tutorial to create a custom toolchain. The text does not help much because they are actually writing a cross tool while what I am trying to do is to tweak the existing host rules and somehow bazel seems to undo every attempt I try to tweak its parameters.
I have got to the point that is currently in my github repository https://github.com/HFTrader/BazelCustomToolchain
However it does not compile and I cannot even figure out how to start debugging this message.
$ bazel build --crosstool_top=#hbclang//:toolchain tensorflow:libtensorflow.so
.....................
ERROR: The crosstool_top you specified was resolved to
'#hbclang//:toolchain', which does not contain a CROSSTOOL file. You can
use a crosstool from the depot by specifying its label.
INFO: Elapsed time: 2.216s
I have appended these lines to my tensorflow/WORKSPACE
new_local_repository(
name="hbclang",
path="/home/hbucher/BazelCustomToolchain",
build_file = "/home/hbucher/BazelCustomToolchain/BUILD",
)
I have asked this question on bazel's google groups but they redirected me to stackoverflow. At this point I am about to give up.
Have someone attempted to do this or I'm breaking ground here?
Thank you.
Solved. Not in the intended way but it works for me.
export INSTALL_DIR="$HOME/install"
export CC=$INSTALL_DIR/bin/clang
export CXX=$INSTALL_DIR/bin/clang++
export CXXFLAGS="-stdlib=libc++ -L$INSTALL_DIR/lib"
export LDFLAGS="-L$INSTALL_DIR/lib -lm -lrt"
export LD_LIBRARY_PATH="/usr/lib:/lib/x86_64-linux-gnu/:$INSTALL_DIR/lib"
git clone https://github.com/tensorflow/tensorflow.git tensorflow-github
cd tensorflow-github
mkdir build-tmp && cd build-tmp
cmake ../tensorflow/contrib/cmake/
make -j4
Easy as 1-2-3 with cmake
[2020-05-24: Edit to make the answer up to date.]
TLDR: To build a project with Bazel with a specific Clang binary, and with libc++, this works for me (where INSTALL_DIR is where I've installed llvm):
CC="$INSTALL_DIR/bin/clang" \
BAZEL_CXXOPTS="-stdlib=libc++:-isystem$INSTALL_DIR/include" \
BAZEL_LINKOPTS="-stdlib=libc++" \
BAZEL_LINKLIBS="-L$INSTALL_DIR/lib:-Wl,-rpath,$INSTALL_DIR/lib:-lc++:-lm" \
bazel test //...
Background:
You can use --repo_env option, e.g. --repo_env=CC=clang, to put these defaults into your project- or system-wide .bazelrc.
This approach uses Bazel's C++ toolchain autoconfiguration which doesn't attempt to declare all the toolchain inputs in BUILD files. This is to simplify the configuration for the user. Therefore whenever you modify the C++ toolchain in a way that Bazel cannot know about (rebuild llvm etc.), you have to run bazel clean --expunge to flush the cache and rerun the autoconfiguration the next time.
The robust solution to specifying C++ toolchain in Bazel is to use the CcToolchainConfigInfo. See the documentation at https://docs.bazel.build/versions/master/tutorial/cc-toolchain-config.html and https://docs.bazel.build/versions/master/cc-toolchain-config-reference.html.
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.
For my project (library), I use configure with libtool and automake to build under linux hosts. The library consists of a C API, as well as an optional C++ extension. So, since
AC_PROG_CXX must be called globally, I use automake conditionals:
*configure.ac*:
AC_PROG_CC
AC_PROG_CXX
AM_PROG_AR
LT_INIT
... some tests to figure out 'build_cxx' ...
AC_CONDITIONAL([CXX], [ test x$build_cxx = xyes ])
And inside Makefile.am
sources = files.c
if CXX then
cxx_sources = files.cpp
else
cxx_sources =
endif
sources = $sources $cxx_sources
The whole thing, however, does not work when configure is not able to locate g++ (which practically kills the extra logic for the c++ extension). After some research, I've come down to the conclusion that AC_PROG_CXX somehow tells libtool to assume that c++ support. I was also surprised to realise that if AC_PROG_CXX fails, it sets CXX to 'g++'!!!
Anyway, calling AC_PROG_CXX conditionally produces errors like 'am_fastdepCXX is never defined', which seems logical to me. The worst thing is that the error is not shown while configure is running, but it appears later in the linking phase, in to form of 'unknown libtool option -o' (ouch).
The full source code can be found here -> http://bitbucket.org/sdlu/sdlu/src
Can somebody help me?
Thanks in advance...
It's an Automake limitation, it doesn't care about the condition when choosing the linker.
One work-around is to conditionally rewrite the _LINK command, as suggested in this mailing list post:
if USE_CXX
cxx_sources = ...
else
cxx_sources =
libSDLU_la_LINK = $(LINK) $(libSDLU_la_CFLAGS) $(libSDLU_la_LDFLAGS)
endif
Another way (suggested in the same discussion) is to put the C++ sources in a utility library that is built and added conditionally, then added to the main library:
if CXX
noinst_LTLIBRARIES = libSDLUxx.la
libSDLUxx_la_SOURCES = src/cxx/SDLU_CButton.cxx \
src/cxx/SDLU_CIniHandler.cxx \
src/cxx/SDLU_CRenderer.cxx \
src/cxx/SDLU_CSprite.cxx \
src/cxx/SDLU_CTexture.cxx \
src/cxx/SDLU_CWindow.cxx
libSDLU_la_LIBADD = libSDLUxx.la
endif
Some unrelated notes
Do not put generated files (Makefile.in, configure, etc) into source control.
Add a bootstrap script that invokes the autotools to generate things.
Prefer pkg-config (i.e. PKG_CHECK_MODULES(SDL2, sdl2)) over hand-crafted autoconf macros (i.e. AM_PATH_SDL2);
Do not install autoheaders (i.e. SDLU_config.h.in). It makes your library incompatible with every autoconf-based software, as you are re-defining PACKAGE, VERSION, and all library-detection macros. See my answer in this question for examples on how to do it.
I would have the C++ API built and installed as an independent, optional library; drop the sdlu-config script altogether, then write sdluxx.pc that requires sdlu. Do not bother checking if the C++ compiler works, if the user passed --enable-cxx he knows what he's doing; I prefer to have the build fail than silently have an incomplete library.
I don't think it is a good idea to interfere in the handling of the CXX variable.
Use your own variable BUILD_CXX
AC_CONDITIONAL([BUILD_CXX], [ test x$build_cxx = xyes ])here
and
if BUILD_CXX
# ....
endif
I've tried enabling C++11 in CDT by adding AX_CXX_COMPILE_STDCXX_11 to my configure.ac file. I've tried moving it around in the file, this seems like the only place where it doesn't error out. I've even tried adding the optional noext flag, but that gives me a syntax error.
The code I'm trying to compile is:
#include <iostream>
#include <memory>
void
print_hello(){
std::unique_ptr<char[]> cha;
std::cout << "11?" << std::endl;
}
Where unique_ptr is of course a c++11 feature.
This is how my configure.ac looks:
dnl Process this file with autoconf to produce a configure script.
AC_PREREQ(2.64)
AC_INIT(fooProj, 1.0)
AC_CANONICAL_SYSTEM
AC_PROG_CXX
AC_LANG([C++])
AX_CXX_COMPILE_STDCXX_11
dnl Initialize automake
AM_INIT_AUTOMAKE
dnl this allows us specify individual liking flags for each target
AM_PROG_CC_C_O
dnl Initialize Libtool
LT_INIT
dnl Check if Libtool is present
dnl Libtool is used for building share libraries
AC_PROG_LIBTOOL
AC_CONFIG_FILES(Makefile
exampleProgram/Makefile
libTestLib/Makefile
include/Makefile)
AC_OUTPUT
If all your want is make your code compile to the C++11 standard, then clean your build, then add AM_CXXFLAGS = -std=c++11 to the Makefile.am where your source is, then rebuild. The AX_CXX_COMPILE_STDCXX_11 in configure.ac is unnecessary for this.
You need an m4 macro from this page on the gnu website [1]. Save it as ax_cxx_compile_stdcxx_11.m4 in your project root.
[1]: http://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx_11.html ""
sudo apt-get install autoconf-archive
I would like to do the following: If CCache is present in PATH, use "ccache g++" for compilation, else use g++. I tried writing a small my-cmake script containing
CC="ccache gcc" CXX="ccache g++" cmake $*
but it does not seem to work (running make still does not use ccache; I checked this using CMAKE_VERBOSE_MAKEFILE on).
Update:
As per this link I tried changing my script to
cmake -D CMAKE_CXX_COMPILER="ccache" -D CMAKE_CXX_COMPILER_ARG1="g++" -D CMAKE_C_COMPILER="ccache" -D CMAKE_C_COMPILER_ARG1="gcc" $*
but cmake bails out complaining that a test failed on using the compiler ccache (which can be expected).
As of CMAKE 3.4 you can do:
-DCMAKE_CXX_COMPILER_LAUNCHER=ccache
It is now possible to specify ccache as a launcher for compile commands and link commands (since cmake 2.8.0). That works for Makefile and Ninja generator. To do this, just set the following properties :
find_program(CCACHE_FOUND ccache)
if(CCACHE_FOUND)
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE ccache)
set_property(GLOBAL PROPERTY RULE_LAUNCH_LINK ccache) # Less useful to do it for linking, see edit2
endif(CCACHE_FOUND)
It is also possible to set these properties only for specific directories or targets.
For Ninja, this is possible since version 3.4.
For XCode, Craig Scott gives a workaround in his answer.
Edit : Thanks to uprego and Lekensteyn's comment, I edited the answer to check if ccache is available before using it as launcher and for which generators is it possible to use a compile launcher.
Edit2: #Emilio Cobos recommended to avoid doing that for the linking part as ccache doesn't improve linking speed and can mess with other types of cache like sccache
I personally have /usr/lib/ccache in my $PATH. This directory contains loads of symlinks for every possible name the compiler could be called from (like gcc and gcc-4.3), all pointing to ccache.
And I didn't even create the symlinks. That directory comes pre-filled when I install ccache on Debian.
From CMake 3.1, it is possible to use ccache with the Xcode generator and Ninja is supported from CMake 3.4 onwards. Ninja will honour RULE_LAUNCH_COMPILE just like the Unix Makefiles generator (so #Babcool's answer gets you there for Ninja too), but getting ccache working for the Xcode generator takes a little more work. The following article explains the method in detail, focussing on a general implementation which works for all three CMake generators and making no assumptions about setting up ccache symlinks or the underlying compiler used (it still lets CMake decide the compiler):
https://crascit.com/2016/04/09/using-ccache-with-cmake/
The general gist of the article is as follows. The start of your CMakeLists.txt file should be set up something like this:
cmake_minimum_required(VERSION 2.8)
find_program(CCACHE_PROGRAM ccache)
if(CCACHE_PROGRAM)
# Support Unix Makefiles and Ninja
set_property(GLOBAL PROPERTY RULE_LAUNCH_COMPILE "${CCACHE_PROGRAM}")
endif()
project(SomeProject)
get_property(RULE_LAUNCH_COMPILE GLOBAL PROPERTY RULE_LAUNCH_COMPILE)
if(RULE_LAUNCH_COMPILE AND CMAKE_GENERATOR STREQUAL "Xcode")
# Set up wrapper scripts
configure_file(launch-c.in launch-c)
configure_file(launch-cxx.in launch-cxx)
execute_process(COMMAND chmod a+rx
"${CMAKE_BINARY_DIR}/launch-c"
"${CMAKE_BINARY_DIR}/launch-cxx")
# Set Xcode project attributes to route compilation through our scripts
set(CMAKE_XCODE_ATTRIBUTE_CC "${CMAKE_BINARY_DIR}/launch-c")
set(CMAKE_XCODE_ATTRIBUTE_CXX "${CMAKE_BINARY_DIR}/launch-cxx")
set(CMAKE_XCODE_ATTRIBUTE_LD "${CMAKE_BINARY_DIR}/launch-c")
set(CMAKE_XCODE_ATTRIBUTE_LDPLUSPLUS "${CMAKE_BINARY_DIR}/launch-cxx")
endif()
The two script template files launch-c.in and launch-cxx.in look like this (they should be in the same directory as the CMakeLists.txt file):
launch-c.in:
#!/bin/sh
export CCACHE_CPP2=true
exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_C_COMPILER}" "$#"
launch-cxx.in:
#!/bin/sh
export CCACHE_CPP2=true
exec "${RULE_LAUNCH_COMPILE}" "${CMAKE_CXX_COMPILER}" "$#"
The above uses RULE_LAUNCH_COMPILE alone for Unix Makefiles and Ninja, but for the Xcode generator it relies on help from CMake's CMAKE_XCODE_ATTRIBUTE_... variables support. The setting of the CC and CXX user-defined Xcode attributes to control the compiler command and LD and LDPLUSPLUS for the linker command is not, as far as I can tell, a documented feature of Xcode projects, but it does seem to work. If anyone can confirm it is officially supported by Apple, I'll update the linked article and this answer accordingly.
I didn't like to set a symlink from g++ to ccache. And CXX="ccache g++" didn't work for me as some cmake test case wanted to have just the compiler program without attributes.
So I used a small bash script instead:
#!/bin/bash
ccache g++ "$#"
and saved it as an executable in /usr/bin/ccache-g++.
Then C configured cmake to use /usr/bin/ccache-g++ as C++ compiler.
This way it passes the cmake test cases and I feel more comfortable than having symlinks that I might forget about in 2 or 3 weeks and then maybe wonder if something doesn't work...
I verified the following works (source: this link):
CC="gcc" CXX="g++" cmake -D CMAKE_CXX_COMPILER="ccache" -D CMAKE_CXX_COMPILER_ARG1="g++" -D CMAKE_C_COMPILER="ccache" -D CMAKE_C_COMPILER_ARG1="gcc" $*
Update: I later realized that even this does not work. Strangely it works every alternate time (the other times cmake complains).
Let me add one important item that was not mentioned here before.
While bootstrapping a minimalistic build system from the ubuntu:18.04 docker image, I've found that order of installation makes a difference.
In my case ccache worked fine when calling gcc, but failed to catch invocations of the same compiler by the other names: cc and c++.
To fully install ccache, you need to make sure all compilers are installed first, or add a call to update-ccache symlinks to be safe.
sudo /usr/sbin/update-ccache-symlinks
export PATH="/usr/lib/ccache/:$PATH"```
... and then (due to updated symlinks) also calls to cc and c++ get caught!
In my opinion the best way is to symlink gcc,g++ to ccache, but if you would like to use within cmake, try this:
export CC="ccache gcc" CXX="ccache g++" cmake ...
Here are 2 methods I think are clean/robust, and also don't pollute your CMake code.
1.) Set environment variables
This method is nice since you don't have to individually set it up for each CMake project. The con is you may not want ccache for each CMake project.
# Requires CMake 3.17 (https://cmake.org/cmake/help/latest/envvar/CMAKE_LANG_COMPILER_LAUNCHER.html)
export CMAKE_CXX_COMPILER_LAUNCHER=/usr/bin/ccache
export CMAKE_C_COMPILER_LAUNCHER=/usr/bin/ccache
2.) Pass in cache variables during project configuration
Con a bit annoying to do for each project. This can be negated by your IDE though.
# Requires CMake 3.4
$ cmake ... -D CMAKE_CXX_COMPILER_LAUNCHER=/usr/bin/ccache \
-D CMAKE_C_COMPILER_LAUNCHER=/usr/bin/ccache
NOTE: It isn't really necessary to specify the full path.
If ccache is in your path you can just specify ccache instead.
export CMAKE_CXX_COMPILER_LAUNCHER=ccache
export CMAKE_C_COMPILER_LAUNCHER=ccache
It is extending #Nicolas answer.
Add following line to your cmake file:
list(PREPEND CMAKE_PROGRAM_PATH /usr/lib/ccache)
Or add it as argument to cmake configuration step:
cmake -DCMAKE_PROGRAM_PATH=/usr/lib/ccache