cmake keeps adding the std=gnu++11 option - macos

I'm trying to compile a project in C++ using cmake, and in the page of the project they tell me that it will crash if I don't add the standard 98. (I'm on a mac)
I've tried all I found on the internet and I could manage to make the cmake use the option -std=c++98 but it also adds -DNDEBUG -std=gnu++11. (I saw it using the make VERBOSE=1 option)
I would like to get rid of that. Using the --trace option I could see that the option is set in a file which is in the cellar folder, that is, is something that has to do with cmake itself and not in the CMakeList.txt file im using.
How can I solve this problem?
If it can help the code I'm trying to compile is this:
SAMoS
Thank you.
UPDATE:
with the --trace option I was able to see that the -std=gnu++11 option was selected in the file:
/usr/local/Cellar/cmake/3.9.4.1/share/cmake/Modules/Compiler/GNU-CXX.cmake
which can be seen here GNU-CXX.cmake
If I eddit that file in a way that every if sets the option to -std=c++98 then, the cmake complains giving me the next error:
CMake Error in src/CMakeLists.txt:
The compiler feature "cxx_nullptr" is not known to CXX compiler
"GNU"
version 7.2.0.
I don't know what else can I try...

You need to set the language standard:
set(CMAKE_CXX_STANDARD 98)
Depending on the compiler, it may enable extensions as well. To disable the GNU extensions also add:
set(CMAKE_CXX_EXTENSIONS OFF)
Note that setting this options does so only for the specified target and dependent targets.
Have take a look at this section of the CMake manual for more information on compiler features. Do note however, using this

The inclusion of VTK is polluting SAMoS's CMake scope with the C++11 requirement. You can test this by disabling VTK on your cmake command line.
$ cd ~SAMoS
$ mkdir build; cd build
$ cmake -DVTK_FOUND=FALSE ../
[...]
$ make VERBOSE=1
[...]
Scanning dependencies of target samos
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/CMakeFiles/samos.dir/build.make src/CMakeFiles/samos.dir/build
[ 1%] Building CXX object src/CMakeFiles/samos.dir/samos.cpp.o
cd /Users/nega/SAMoS/build/src && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -DCGAL_USE_GMP -DCGAL_USE_MPFR -DHAS_CGAL -isystem /usr/local/include -I/include -I/Users/nega/SAMoS/src/constraints -I/Users/nega/SAMoS/src/dump -I/Users/nega/SAMoS/src/log -I/Users/nega/SAMoS/src/integrators -I/Users/nega/SAMoS/src/messenger -I/Users/nega/SAMoS/src/parser -I/Users/nega/SAMoS/src/potentials -I/Users/nega/SAMoS/src/potentials/external -I/Users/nega/SAMoS/src/potentials/pair -I/Users/nega/SAMoS/src/potentials/bond -I/Users/nega/SAMoS/src/potentials/angle -I/Users/nega/SAMoS/src/system -I/Users/nega/SAMoS/src/utils -I/Users/nega/SAMoS/src/aligner -I/Users/nega/SAMoS/src/aligner/pair -I/Users/nega/SAMoS/src/aligner/external -I/Users/nega/SAMoS/src/population -I/Users/nega/SAMoS/src -I/Users/nega/SAMoS/build -DNDEBUG -o CMakeFiles/samos.dir/samos.cpp.o -c /Users/nega/SAMoS/src/samos.cpp
You'll notice there's no -std=gnu++11 flag anymore. Of course, since it looks like you're GCC version 7.2, you'll still want your set CMAKE_CXX_STANDARD to 98 since gcc-7.2 uses C++11 by default. (Or maybe it's C++14 now...) You can do this on your cmake command line.
$ cmake -DUSE_VTK=FALSE -DCMAKE_CXX_STANDARD=98 ..
CMake will then add -std=gnu++98 to its compile commands.
If you can't live without VTK, then you'll need to send a bug report upstream asking the SAMoS folks to clarify their documentation, or fix how they're including VTK.

Related

Avoid cmake to add the flags -search_paths_first and -headerpad_max_install_names in MacOS

I'm building an *.elf file for ARM within MacOS using cmake. CMake is adding the flags -Wl,-search_paths_first -Wl,-headerpad_max_install_name automatically, which leads to produce an invalid *.elf file. I obtain the error warning: cannot find entry symbol arch_paths_first; defaulting to 00000000080001e0.
I have tried to execute the arm gcc command without that options and it works perfectly.
How can I stop cmake to add these flags?
I have found a way to do that.
It's necessary to add the following directive:
set(HAVE_FLAG_SEARCH_PATHS_FIRST 0)
I'm pretty sure that it must be added before the project directive.
For removing the flag -headerpad_max_install_names, I have written the following after the project directive:
set(CMAKE_C_LINK_FLAGS "")
I guess that if I were using g++ I should needed to add
set(CMAKE_CXX_LINK_FLAGS "")

How to override default linker compiling with configure?

I need to install a package (ROOT) from source on OSX using GCC 4.7.3 as a compiler. Default compiler on OSX is clang, so I look to configure command options to change it. I see that I can change it:
with compiler options, prefix with --with-, overrides default value
cc alternative C compiler and options to be used
cxx alternative C++ compiler and options to be used
But when I run:
./configure --with-cxx=g++ --with-cc=gcc
I see:
Checking for C compiler ... gcc
Checking for C++ compiler ... g++
Checking for linker (LD) ... clang++
So it trying to compile with gcc and link with clang, this obviously leads to failure. But I can't find an option in configure how to change linker used by make.
Is there a default options of configure to change linker? Something like --with-cxxlinker.
If not - how can I find and change the linker used by specific package?
The recommended way of building ROOT from source is to use git and obtain the most recent production version available. As of today that is version 5.34.19.
Open Terminal.app (then use each of the commands in succession):
cd ~/desktop && mkdir root
git clone http://root.cern.ch/git/root.git && cd root
./configure
make
make install
The nice thing about using git is that it contains a complete source tree for all systems (72 MB). You shouldn't need to use any special ./configure commands (unless you want to use add-on components).
You could also install the Mac Ports version by using the command:
sudo port install root

mingw32-make tries to create subfolder .lib an illegal name

I am trying to compile a project that required freetype library so I was figuring out how to install freetype to mingw32 and the more safer way is to compile it.
Anyway the problem was compiling freetype-2.4.11
I went into bash provided in msys
I did ./configure within freetype's main dir and everything looks fine
next I did mingw32-make which created the problem
libtool: compile: gcc -pedantic -ansi -Ig:/Downloads/freetype-2.4.11/objs -I./b
uilds/unix -Ig:/Downloads/freetype-2.4.11/include -c -Wall -g -O2 "-DFT_CONFIG_C
ONFIG_H=<ftconfig.h>" -DFT2_BUILD_LIBRARY "-DFT_CONFIG_MODULES_H=<ftmodule.h>" g
:/Downloads/freetype-2.4.11/src/base/ftsystem.c -DDLL_EXPORT -DPIC -o g:/Downlo
ads/freetype-2.4.11/objs/.libs/ftsystem.o
Assembler messages:
Fatal error: can't create g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o: No
such file or directory
g:/Downloads/freetype-2.4.11/builds/freetype.mk:198: recipe for target 'g:/Downl
oads/freetype-2.4.11/objs/ftsystem.lo' failed
mingw32-make[4]: *** [g:/Downloads/freetype-2.4.11/objs/ftsystem.lo] Error 1
g:/Downloads/freetype-2.4.11/objs/.libs/ftsystem.o seemed like it is trying to use a directory that is illegal in windows.
Thanks in advance
Try to use make instead (i.e. the one from MSYS distribution), and avoid using mingw32-make (from MinGW distribution) in the future to save yourself time and nerves. Extract from MinGW Wiki:
What's the difference between make and mingw32-make?
The "native" (i.e.: MSVCRT dependent) port of make is lacking in some functionality and has modified functionality due to the lack of POSIX on Win32. There also exists a version of make in the MSYS distribution that is dependent on the MSYS runtime. This port operates more as make was intended to operate and gives less headaches during execution. Based on this, the MinGW developers/maintainers/packagers decided it would be best to rename the native version so that both the "native" version and the MSYS version could be present at the same time without file name collision.

Cmake ignoring CMAKE_BUILD_TYPE=Debug

I am trying to include debug/release dependent compiler flags, such as:
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=gnu++0x -Wall -DUSE_BOOST")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -Wall")
set(CMAKE_CSS_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -Wall -O3")
I create my build folder with a command such as:
cmake -DCMAKE_BUILD_TYPE=Release -D UseFortran=True -D CMAKE_CXX_COMPILER=g++-4.6 ~/repos/cliques/cliques
However it seems with CMAKE version 2.8.7, CMAKE_BUILD_TYPE is being ignored. It seems to work perfectly with version 2.8.4 (on a different machine), so has this method been deprecated or is there some other problem here?
Zenna
You have a typo. Your code says CMAKE_CSS_FLAGS_RELEASE. Notice CSS, it should be CXX.
The problem was that there must be a space between the -D and the variable. That is, it should be:
cmake -D CMAKE_BUILD_TYPE=Release -D UseFortran=True -D CMAKE_CXX_COMPILER=g++-4.6 ~/repos/cliques/cliques
I think they made a Typo In CMAKE_BUILD_TYPE in the previous version. We had this porblem and here a line that works.
cmake -D CMAKE_BUILD_TYPE:STRING=Debug ../src
You may check that every things went fine using:
cmake -L ../src
Using this command may give you the right way to name the variable CMAKE_BUILD_TYPE.
Good luck.
Why are you not using -DCMAKE_BUILD_TYPE=Debug, when creating build folder?
Cmake build Release type project or Debug type project, not both together.

Problem compiling gcc 4.4.0 on OpenSolaris 2009.6

I am attempting to compile gcc 4.4.0 on opensolaris 2009.6
Currently in the box (which is a AMD 64bit machine), I have the gcc 3.4.6 installed.
I unpacked the gcc 4.4.0 tarball.
I set the following env variables:
export CXX=/usr/local/bin/g++
export CC=/usr/local/bin/gcc
Then I ran "configure && make" and this is the error message that I got:
checking for i386-pc-solaris2.11-gcc... /export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/xgcc -B/export/home/me/wd/gcc/gcc-4.4.0/host-i386-pc-solaris2.11/gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64
checking for suffix of object files... configure: error: in `/export/home/me/wd/gcc/gcc-4.4.0/i386-pc-solaris2.11/amd64/libgcc':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
Anyone has any suggestion as to how to work around this error message?
/Edit:
Content of the config.log is posted here: link text
Normally the GCC build is bootstrapped, i.e. first it uses the system compiler to build GCC C compiler, and then it uses the freshly built compiler to recompile GCC once again (and then even once more time again). The configure line shows that it is not the system compiler but the already-built GCC compiler which is used for configure test there.
Since it fails, the problem is that the freshly-built GCC is somehow "stillborn" here. If config.log will not help you, I'd suggest to ask at gcc-help#gcc.gnu.org.
EDIT: Ah-ha, I think it is the assembler. You are using GNU assembler, but the unsupported options look like they were meant for Sun assembler. This should be solved by adding --with-gnu-as configure option (and then possibly having to specify its path explicitly with --with-as=/usr/gnu/bin/as)
You can also take a look at Solaris-specific GCC build instructions.
There's a readily available build for gcc4, which you can try updating. Its current version is 4.3.3. To get started, install pkg-get from OpenCSW and check out the build from the subversion repository:
svn co https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg/gcc4/trunk/ gcc4
cd gcc4
gmake package

Resources