I figured out that CUDA does not work in 64bit mode on my mac (or couldn't get it running so far). Therefore I decided to compile everything for 32bit.
I use cmake 2.8 and added the following options
add_definitions(-Wall -m32)
set(CUDA_64_BIT_DEVICE_CODE OFF)
set(CMAKE_MODULE_LINKER_FLAGS -m32)
However when it tries to link it it does something like this:
/usr/bin/c++ -mmacosx-version-min=10.6 -Wl,-search_paths_first -headerpad_max_install_names CMakeFiles/SimpleTestsCUDA.dir/BlockMatrix.cpp.o CMakeFiles/SimpleTestsCUDA.dir/Matrix.cpp.o ./SimpleTestsCUDA_generated_SimpleTests.cu.o ./SimpleTestsCUDA_generated_BlockMatrix.cu.o -o SimpleTestsCUDA /usr/local/cuda/lib/libcudart.dylib /usr/local/cuda/lib/libcuda.dylib
Which fails with a lot of "file is not of required architecture" warnings from ld. Now if I add manually -m32 to the command above it works. However I have no idea how to teach cmake to add -m32 to every gcc (or ld) invocation. So far it does it for nvcc and gcc, but not for linking..
If you set the env var LDFLAGS before you run cmake on the project it will work as well:
export LDFLAGS=-m32
cmake ../source
see above
set(CMAKE_C_FLAGS -m32)
set(CMAKE_CXX_FLAGS -m32)
Another solution might be to say:
if (Apple)
set (CMAKE_OSX_ARCHITECTURES i386)
set (CUDA_64_BIT_DEVICE_CODE OFF)
endif (Apple)
Hope this helps.
Related
CMake 3.9, arm-gcc 5.4.1, Linux / OSX:
I'm enabling stack smashing protection by adding -fstack-protector-strong to my compiler flags. This instructs gcc to look for specially-named symbols in the hard-coded libraries libssp.a and libssp_nonshared.a.
These libraries exist in my application as part of the build, but they do not yet exist when CMake is interrogating my compiler during the configuration phase.
This causes CMake to fail, which makes sense:
[2/2] Linking CXX executable cmTC_0f43d
FAILED: cmTC_0f43d
/path/to/arm-none-eabi-g++ -fstack-protector-strong
CMakeFiles/cmTC_0f43d.dir/testCXXCompiler.cxx.obj -o cmTC_0f43d
/path/to/arm-none-eabi/bin/ld: cannot find -lssp_nonshared
/path/to/arm-none-eabi/bin/ld: cannot find -lssp
Is there any way to:
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Provide an empty "dummy" version of libssp and libssp_nonshared during interrogation?
Skip compiler interrogation entirely? (This is a custom toolchain.)
Or any other way to work around this?
Tell CMake to not use -fstack-protector-strong during compiler interrogation?
Just add this compiler flag after the project() call, when CMake checks a compiler.
project(MyProject)
# ...
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -fstack-protector-strong")
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fstack-protector-strong")
Instead of appending the flag to CMAKE_*_FLAGS variable, you may also add it via add_compile_options command:
project(MyProject)
# ...
add_compile_options("-fstack-protector-strong")
In my case, option 3 turned out to be easy. In my toolchain CMake file, I simply added:
set(CMAKE_C_COMPILER_WORKS ON)
set(CMAKE_CXX_COMPILER_WORKS ON)
And now CMake doesn't waste any time interrogating the features of my compiler.
This works in my specific case (embedded systems firmware), but it would be nice how to get CMake and -fstack-protector-strong to work on non-embedded programs as well.
We are catching link errors on Solaris with makefiles generated by CMake 3.6.2. In the testing below, we are using GCC and not SunCC. From the looks of it, CMake is applying our options inconsistently:
Typical compile command
[ 2%] Building CXX object CMakeFiles/cryptopp-object.dir/cpu.cpp.o
/bin/c++ -fPIC -march=native -m64 -Wa,--divide -o CMakeFiles/cryptopp-object.dir/cryptlib.cpp.o
-c /export/home/jwalton/cryptopp/cpu.cpp
Abbreviated link command
/bin/c++ CMakeFiles/cryptest.dir/bench1.cpp.o CMakeFiles/cryptest.dir/bench2.cpp.o
...
CMakeFiles/cryptest.dir/fipstest.cpp.o -o cryptest.exe libcryptopp.a -lnsl -lsocket
Typical link error
ld: fatal: file CMakeFiles/cryptopp-object.dir/cryptlib.cpp.o: wrong ELF class: ELFCLASS64
Notice the file was compiled with -march=native -m64 (its a 64-bit capable machine and kernel), but the link invocation is missing it (the default is 32-bit on Solaris).
Attempting to search for "cmake use CXXFLAGS link" is producing too much irrelevant noise, and I'm not having much luck finding the CMakeList.txt option. I also want to avoid duplicating the work into LDFLAGS, or performing the work of reformatting the options (CXXFLAGS option -Wl,-x becomes LDFLAGS option -x).
How do I instruct CMake to use both CXX and CXXFLAGS when driving link?
I found Running a different program for the linker on the CMake users mailing list, but it does not feel right to me (also, the problem and context are slightly different). It also does not work.
Here is a small example:
PROJECT(foo)
SET(CMAKE_CXX_LINK_EXECUTABLE
"purify <CMAKE_CXX_COMPILER> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>")
ADD_EXECUTABLE(foo foo.cxx)
I also found Setting global link flags on the mailing list. It does not work, either.
SET(CMAKE_EXE_LINKER_FLAGS "${CMAKE_CXX_FLAGS}")
SET(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_CXX_FLAGS}")
SET(CMAKE_MODULE_LINKER_FLAGS "${CMAKE_CXX_FLAGS}")
One of my users is getting an error message when trying to compile a C part of our mixed C/C++ codebase on ubuntu 12.04 with gcc 4.8.1
We have a library in C++ with some C-linkage functions in, and want to compile a C program linking to it. The library is compiled with g++ and builds fine. The c program fails like this:
> gcc -O3 -g -fPIC -I/media/Repo/lcdm/code/cosmosis/ -Wall -Wextra -pedantic -Werror -std=c99 -o c_datablock_t c_datablock_test.c -L . -lcosmosis
cc1plus: error: command line option ‘-std=c99’ is valid for C/ObjC but not for C++ [-Werror]
The program has a lower case .c file suffix, so why does gcc try to compile it as c++ ? We have not seen this on other OSes.
(I know we could kick the problem down the road by removing -Werror or handle this particular file with -x c but I'd like to solve the real problem.)
why does gcc try to compile it as c++
I can think of only two plausible explanations, and they both are end-user's fault.
It could be that the user transferred sources via Windows, and the file is really called C_DATABLOCK_TEST.C, and the user is misleading you.
It could also be that the user overwrote his gcc with g++ (surprisingly many people believe that gcc and g++ are the same thing, but they are not).
To disprove the first possibility, ask the user to execute his build commands under script, and send you resulting typescript.
To disprove the second, ask the user to add -v to the compile command.
This look like GCC Bug 54641, which has been fixed in a later release of GCC. It is only a warning, but your compile flags are causing GCC to treat all warnings as errors.
I've downloaded MinGW from this link x64-4.8.1-posix-sjlj-rev1 but when I try to build for x86 target I've lots of linkage errors... seems that only x64 lib are installed...
I've need to build for x86 and x64 platforms on windows... Have I to download both x64 and x86 or are some simpler ways?
Edit I'm using eclipse keplero as IDE
I've tryed to build myself a simple hello world program with g++ -m32 -std=c++11 test.cpp -o test32.exe and g++ -m64 -std=c++11 test.cpp -o test64.exe. And all is ok... So the problem was with eclipse... After a little a discovered that I need to use MYSY ( set in PATH ) and set -m32 also in the c++ linkage options...
Now all is fine.
I've also tryed to use NetBeans C++ as IDE... seems a gread IDE!!!
It is not multilib enabled. That's why you are not able to compile 32-bit(x86) program. You can get multilib enabled toolchain from following link:
For 64-bit machine: 64-Bit
For 32-bit machine: 32-Bit
I'm trying to build google-glog on Mac OS X 10.8, using following options:
./configure CXX='clang++' CXXFLAGS='-std=c++11 -stdlib=libc++'
Despite that the library gets linked with libstdc++.
Why, and how to fix this?
It's better to put 'dialect' and runtime flags in the compiler variable, since it will use those flags for linking - not just source compilation: CXX="clang++ -std=c++11 -stdlib=libc++"
Save CXXFLAGS for things like -W -Wall -O2 -march=xxx, etc.
Found out that you could use the build variable
LIBS+="-stdlib=libc++"
Seems to me a better place than the compiler variables.