I was trying to convert an existed c++ project to CMake. The existed worked well with makefile, and i have converted similar one successfully. but when i try to convert this one, some confusing errors occurred, as below：
18:22:10: Running steps for project encryption...
18:22:10: Starting: "/export/opt/cmake-3.2.2/bin/cmake" --build . --target all
Linking CXX executable dist/Debug_64/GNU-Linux-x86/encryption
CMakeFiles/encryption.dir/encryption.cc.o: In function `main':
/export1/chao/nanos/nano_clean/nano_clean/src/encryption/encryption.cc:33: undefined reference to `stlp_std::cout'
...
/export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/stl/_string.c:604: undefined reference to `stlp_std::__stl_throw_out_of_range(char const*)'
...
At first i think it can't find iostream, so i include iostream at /export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/ by using 'INCLUDE_DIRECTORIES', but it did not work. Could you please give me some advices?
My CMakeLists.txt as below:
include_directories(/export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport)
include_directories(/export1/chao/nanos/nano_clean/nano_clean/lib/STLport/stlport/h/using)
include_directories(/export1/chao/nanos/nano_clean/nano_clean/lib/boost/1.49.0/boost/tr1/tr1)
link_directories(
../common/dist/${CONF}/GNU-Linux-x86
/export2/chao/nanos/nano_built/lib/tiburonda/dist/include
)
aux_source_directory(. SRC_LIST)
include_directories(../common/include
)
add_executable(encryption ${SRC_LIST})
target_link_libraries(encryption libcommon.a)
According to original makefile, i found this project use source file encryption.cc at ./, header files: encryption.h at ./ and others at ../common/include.
Related
I was trying to build a llvm-slicer from:
https://github.com/IAIK/ios-analysis-llvmslicer
and I follow the instructions:
cd llvm-slicer
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLLVM_ENABLE_EH=YES -DLLVM_ENABLE_RTTI=ON ..
make -j4 opt
make -j4 llvm-slicer
But when I execute the last command make -j4 llvm-slicer, I got an error:
[100%] Built target LLVMAnalysis
[100%] Linking CXX executable ../../bin/llvm-slicer
/usr/bin/ld: ../../lib/libLLVMSlicer.a(FunctionStaticSlicer.cpp.o): in function `llvm::Pass* llvm::callDefaultCtor<(anonymous namespace)::FunctionSlicer>()':
FunctionStaticSlicer.cpp:(.text._ZN4llvm15callDefaultCtorIN12_GLOBAL__N_114FunctionSlicerEEEPNS_4PassEv+0x1c): undefined reference to `vtable for (anonymous namespace)::FunctionSlicer'
collect2: error: ld returned 1 exit status
make[3]: *** [tools/llvm-slicer/CMakeFiles/llvm-slicer.dir/build.make:116: bin/llvm-slicer] Error 1
make[2]: *** [CMakeFiles/Makefile2:9647: tools/llvm-slicer/CMakeFiles/llvm-slicer.dir/all] Error 2
make[1]: *** [CMakeFiles/Makefile2:9654: tools/llvm-slicer/CMakeFiles/llvm-slicer.dir/rule] Error 2
make: *** [Makefile:2740: llvm-slicer] Error 2
I have no idea about how to fix it and I couldn't find any similar issues on Google, I hope someone can help me to figure it out, many thx.
There can be several scenarios for this issue, but in my opinion, here the scenario is for the given information that your default compiler (_ZN...something errors mostly because of compilers or linkers) is earlier version of gnu (gcc for c, g++ for c++) in your host pc (or maybe another compiler other than clang) and struggling about resolving a c++ feature anonymous namespace, as, a part of given error says:
/usr/bin/ld: ../../lib/libLLVMSlicer.a(FunctionStaticSlicer.cpp.o): in function `llvm::Pass* llvm::callDefaultCtor<(anonymous namespace)::FunctionSlicer>()':
FunctionStaticSlicer.cpp:(.text._ZN4llvm15callDefaultCtorIN12_GLOBAL__N_114FunctionSlicerEEEPNS_4PassEv+0x1c): undefined reference to `vtable for (anonymous namespace)::FunctionSlicer'
For this, there are several things you can do:
1-) You can change your compiler for building. In command window, you can export clang and clang++ as your compiler before cmake configuration. Here I assume that you installed new versions of clang compiler from anywhere, even github clone, I can give several examples here how to export and you can adapt one of them to your case easily:
export CC=clang
export CXX=clang++
another version:
export CC=clang-11
export CXX=clang++-11
another version:
export CC=/usr/bin/clang
export CXX=/usr/bin/clang++
another version:
export CC=/usr/bin/clang-12
export CXX=/usr/bin/clang++-12
another github clone version:
export CC=~/llvm/llvm-project/build/bin/clang
export CXX=~/llvm/llvm-project/build/bin/clang++
Even if this does not change your compiler, you can change your compiler while configuring with cmake by -DCMAKE_C_COMPILER={your-c-compiler} and -DCMAKE_CXX_COMPILER={your-c++-compiler} cmake flags. Try either with gcc or clang. Here is an example configuration in your case:
cmake \
-DCMAKE_C_COMPILER=clang \
-DCMAKE_CXX_COMPILER=clang++ \
-DCMAKE_BUILD_TYPE="Release" \
-DLLVM_TARGETS_TO_BUILD="AArch64;X86" \
-DLLVM_ENABLE_EH=YES \
-DLLVM_ENABLE_RTTI=ON ..
2-) Error can be because of c++ standard, you can add -DCMAKE_CXX_STANDARD=14 (Default C++ standard using by LLVM) flag as cmake configuration like:
cmake -DCMAKE_BUILD_TYPE="Release" -DLLVM_TARGETS_TO_BUILD="AArch64;X86" -DLLVM_ENABLE_EH=YES -DLLVM_ENABLE_RTTI=ON -DCMAKE_CXX_STANDARD=14 ..
3-) Even if didn't work above cases, you can remove anonymous namespace from FunctionStaticSlicer.cpp file (given in the error message) and try to build again. You can find these lines like this:
// some code here and do not delete
namespace { // delete this line
// as you can see there is no name of namespace that's why called 'anonymous'
// if it was it would be like 'namespace nmspcName {'
// some code here and do not delete
} // and delete this line, too
// some code here and do not delete
But this is really bad practice, even if it can solve your problem, I do not recommend.
Also you can try to do similar changes in CMakeLists.txt file or adding other cmake configuration flags, however in my opinion, you could solve your problem easily by 1. option which is changing your default compiler.
I have a CMake project that I compile with gcc on Linux. Because of how CMake invokes gcc in subdirectories, gcc outputs only the base file name when it encounters an error:
[100%] Building C object path/file.c.o
cd /absolute/path && /usr/bin/cc [...]
file.c: In function ‘foo’:
file.c:85:5: error: unknown type name ‘bar’
How can I see the full file path in the gcc output? Any solution through either CMake or gcc configuration would be acceptable. I want to see something like this:
/absolute/path/file.c:85:5: error: unknown type name ‘bar’
or
path/file.c:85:5: error: unknown type name ‘bar’
(preferrably the former).
I found the problem. Showing the full path should have been the default behaviour requiring no extra configuration. The compiler was showing only the file name because of a #line pre-processor directive in my source file.
-- Question solved --
This question is solved. Thanks for all the help!
The problem and the reason is briefly stated as following for other readers in the future:
[Environment]
Ubuntu 14.04, Bazel, C++
[Question]
I want to include an external library. So I download the source file and make it as as a static lib .a.
I correctly set the BUILD, WORKSPACE and related files. However, when compile, it alerts the error:
Linking of rule '//main' failed (Exit 1)
main: error: undefined reference to 'void ex_lib::compute(double*, double const*, double const*)'
collect2: error: ld returned 1 exit status
I tried with the .lo and alwayslink method here but doesn't work.
Alternate to "`--whole-archive`" in bazel
[Reason]
It is because that the external library source files contains duplicate header files. So I fix the header file problem. Make the .a again. Then everything works.
So nothing wrong with the bazel. It is the library itself that cause the problem. But the error information is confusing and I think it is caused by bazel.
What you can do to investigate further is to run the clean bazel build with --subcommands to see individual command lines of actions executed. Then you can cd into the sandbox, and execute the same gcc command as bazel does and debug what's wrong. Or you can try to get linking to work by handwriting gcc command, and pasting here both the command bazel generated, and your desired command. Is it possible that you have multiple liegroups libs installed on the system and gcc is getting one that's incompatible with headers you're including?
The problem is solved. Special thanks to mhlopko.
It is mainly because there is errors with the lib source file. Thus .a file I use contains errors. Now the bazel works fine with the new lib file.
By the way, now bazel works fine with both .a or .so file that I generated.
This is on a fairly fresh vanilla Win7 64-bit installation with the latest MinGW64, in a clean (freshly extracted) GLFW 2.7.5 source directory calling their make win32-msys command.
[A] Building the libs
#1 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -o win32_init.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
#2 -- Warning at gcc -c -I. -I.. -Wall -mwin32 -O2 -mdll -DGLFW_BUILD_DLL -D_GLFW_NO_DLOAD_GDI32 -D_GLFW_NO_DLOAD_WINMM -o win32_init_dll.o win32_init.c:
win32_init.c: In function '_glfwPlatformTerminate':
win32_init.c:353:27: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
But the relevant output files do get created in .\lib\win32: glfw.dll, libglfwdll.a and libglfw.a. However I worry those might be corrupted, since it's impossible for me to link to them via gcc later on -- same problem as the last one in this post described further down.
[B] Building the examples
#3 -- Warning at triangle.exe, pong3d.exe, splitview.exe, mipmaps.exe, gears.exe, boing.exe, wave.exe, heightmap.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
Not so however for listmodes.exe, mthello.exe, mtbench.exe and particles.exe which build fine. Indeed those 4 are the only ones running properly here afterwards, the others just exit immediately without outputs or errors (naturally, since there is no valid entry point for them).
[C] Building the tests
Warning at accuracy.exe, dynamic.exe:
c:/mingw64/x86_64-w64-mingw32/bin/ld.exe: warning: cannot find entry symbol _mainCRTStartup; defaulting to 0000000000401000
No such problem for defaults.exe. For dynamic.exe it then proceeds with the following errors:
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x1c): undefined reference to `__imp_glfwGetVersion'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x62): undefined reference to `__imp_glfwInit'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0xcf): undefined reference to `__imp_glfwOpenWindow'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x10b): undefined reference to `__imp_glfwSetWindowTitle'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x118): undefined reference to `__imp_glfwSetWindowSizeCallback'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x123): undefined reference to `__imp_glfwSwapInterval'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x14a): undefined reference to `__imp_glfwGetWindowParam'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x151): undefined reference to `__imp_glfwSwapBuffers'
C:\Users\roxor\AppData\Local\Temp\cc8hsorn.o:dynamic.c:(.text.startup+0x174): undefined reference to `__imp_glfwTerminate'
collect2: ld returned 1 exit status
make[1]: *** [dynamic.exe] Error 1
make[1]: Leaving directory `/c/glfw64/tests'
make: *** [win32-msys] Error 2
Now this latter one is the test program for loading the DLL. You might think that's simply missing the necessary libs (.a and .dll) in the correct places, but do note at this very point I DID have all the necessary includes and libs (from an earlier GLFW make that was exactly the same as the above, same versions, same warnings, same output files) in the correct places:
libglfwdll.a in \MinGW64\x86_64-w64-mingw32\lib (next to libglu32.a, libopengl32.a)
glfw.h in \MinGW64\x86_64-w64-mingw32\include\GL (next to gl.h, glaux.h, glu.h)
glfw.dll in \windows and \windows\system32 (next to opengl32.dll, glu32.dll)
Problem A is harmless but I've added an additional cast to remove the warning. Problems B and C are due to two bugs in GLFW. They have now been fixed, in part thanks to this thread. Thanks for posting it to the GLFW bug tracker and so bringing them to my attention. The fixes will be included in the 2.7.6 release. Until then, you can grab trunk from the GLFW Subversion repository.
Problem C was tricky enough to solve that someone may find a summary useful.
Proper linking for 32-bit requires a .def file with __stdcall decorated symbols, but this file cannot be used for 64-bit. The solution was to have GCC generate the correct .def file for the given architecture.
This is done by linking the DLL twice. First it's linked as exporting __stdcall decorated symbols (the default) and generating the .def file (using -Wl,--output-def,file.def) and then it's linked again without decorations (using --kill-at) to produce the final DLL. This generated .def file can then be used as usual with dlltool to generate the import library.
The most useful resource I found whilst researching this was Stdcall and DLL tools of MSVC and MinGW, which among other things outlines this method.
I got the same error too.
Solved by change the file glfw-2.7.5\tests\Makefile.win32.mingw:12 from
SOLIB = ../lib/win32/libglfwdll.a
to
SOLIB = ../lib/win32/glfw.dll
I ran into the exact same problem and while researching the errors and warning I found a fix for the 'cannot find entry symbol error' warning:
In examples/Makefile.win32.msys and tests/Makefile.win32.msys change the line
WINDOWS = -mwindows -e _mainCRTStartup
to
WINDOWS = -mwindows
Kabie's fix helps with the dynamic linking error
I'm not 100% sure this is a correct solution as I don't completely understand the reason for the alternate entry point name in the first place but at least the tests seem to work and the examples run.
I am stumped by what seems to be a problem that should be easy to diagnose and fix. I have a C++ source file that makes use of the CUDA Driver API. When I compile it using nvcc, the executable is produced and works without problems. However, when I try to compile it using g++, the linker complains about undefined references to symbols that are in /usr/lib/libcuda.so:
undefined reference to cuDeviceGet'
... undefined reference tocuDeviceComputeCapability'
... undefined reference to cuDeviceGetName'
... undefined reference tocuDeviceTotalMem_v2'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
... undefined reference to cuDeviceGetAttribute'
... undefined reference tocuDeviceGetAttribute'
I tried to ensure that /usr/lib is included in the library path (by supplying the flags -L/usr/lib, -lcuda, and adding /usr/lib to $LIBRARY_PATH). However, the problem still persists. I am sure that /usr/lib/libcuda.so contains the symbols that the linker is complaining about:
$ nm -D /usr/lib/libcuda.so | grep cuDeviceGet
00000000000be410 T cuDeviceGet
00000000000bf120 T cuDeviceGetAttribute
00000000000d2e10 T cuDeviceGetByPCIBusId
00000000000be200 T cuDeviceGetCount
00000000000bdfa0 T cuDeviceGetName
00000000000d2bb0 T cuDeviceGetPCIBusId
00000000000bf380 T cuDeviceGetProperties
I find it strange that nvcc successfully compiles the file, but g++ does not. Do you have any idea as to how I can fix this problem?
Thank you very much for your help!
Ok, the reason I was not able to compile the file was because the -lcuda flag has to come after the filename. Otherwise, it won't work... a large, prominent warning with the compiler telling me this information would have been much appreciated. Well, that was a waste of two hours.