Windows VC++ 2008
linux gcc 4.4.3
I have the following problem. When I compile on windows I need the ws2_32 library. However, when I compile on linux, I don't need to link this.
My CMakeLists.txt
INCLUDE_DIRECTORIES($CLIENT_SERVER_SOURCE_DIR/client)
INCLUDE_DIRECTORIES($CLIENT_SERVER_SOURCE_DIR/cltsvr_ults)
# Link the library
LINK_DIRECTORIES($CLIENT_SERVER_DIR/client)
# Add the executable
ADD_EXECUTABLE(clt test_clt)
# Link the executable to the client library
IF(WIN32)
TARGET_LINK_LIBRARIES(clt client ws2_32)
ENDIF(WIN32)
IF(CMAKE_COMPILER_IS_GNUCXXX)
TARGET_LINK_LIBRARIES(clt client)
ENDIF(CMAKE_COMPILER_IS_GNUCXXX)
I have tried unsuccessfully to compile under linux. Using the above conditions. However, It always tries to link the ws2_32 and I get a compile error. I think that the conditions aren't working, as it always falls through the WIN32 condition.
many thanks for any suggestions,
Since the WIN32 thing is such a fundamental part of CMake, I'd guess that there is more to this than what you mention.
Are you doing a clean check out of your code, or just copying up a whole directory on Linux? If you have all your CMake build files cached from the Windows build, maybe (just maybe!) something has snuck in there and "detects" itself as WIN32 on Linux?
Are you sure it is that line and not something else that causes the link to the stray Win-library? Maybe try a MESSAGE(STATUS "I am here")line within the IF(WIN32) just to make sure.
Are you sure the error is caused by linking that library? I can see a typo in your script, it should be IF(CMAKE_COMPILER_IS_GNUCXX) - you have an extra X on there. Perhaps you are not linking in what you thing you are, and that is why it fails.
Related
I'm a *nix user, installing LLVM is easy for me, just download the precompiled file, set LLVM_DIR, and you're done. But I'm having a lot of problems with Windows ...
I downloaded LLVM-<version>-win64.exe from the GitHub release, but I can't find LLVMConfig.cmake file. Then I tried to compile LLVM from the source following this documentation.
When I started compiling my own project, I got this error:
'C:/<...>/Debug/libLLVMSupport.lib', needed by '<...>.exe', missing and no known rule to make it
I guess maybe I'm missing some compile options. but I can't find the documentation for LLVM_ENABLE_PROJECTS or BUILD_SHARED_LIBS, not even a list of component names.
I tried to add -DBUILD_SHARED_LIBS=ON but CMake told me BUILD_SHARED_LIBS option is not supported on Windows.
If you build C++14 code with G++ and libstdc++, there's a library named libstdc++fs, which is separate from the rest of libstdc++, and contains the code for std::experimental::filesystem. If you don't link against it, you'll get undefined references.
The "trick" I'm using for overcoming this right now is:
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
set(CXX_FILESYSTEM_LIBRARIES "stdc++fs")
endif()
and later:
target_link_libraries(my_target PUBLIC ${CXX_FILESYSTEM_LIBRARIES})
but - I don't like having to place this code in every project I work on. Is there a simpler or more standard idiom I could use? Some way this will all happen implicitly perhaps, with some CMake behind-the-scences magic?
tl;dr: Nothing right now, wait for a newer CMake version
As #Pedro graciously points out, this is a known problem, and there is an open issue about it at KitWare's GitLab site for CMake:
Portable linking for C++17 std::filesystem
If using CMAKE_CXX_STANDARD=17 and std::filesystem, GCC requires linking of an extra library: stdc++fs. ... If C++17 is enabled, would it be worth automatically linking to stdc++fs for GCC versions which require this? Likewise for any quirks in other compilers or libraries.
The KitWare issue is about C++17, for which apparently you still need the separate extra library (i.e. it's not just because of the "experimentality" in C++14). Hopefully we'll see some traction on this matter - but
Note: If you're experiencing this problem with C++17's std::filesystem, you're in luck - that code is built into libstdc++ beginning with GCC 9, so if you're using g++ 9 or later, and std::filesystem, you should no longer experience this problem.
How to only build a static library with clion without having an executable?
How does the CMakeLists.txt look like? (without add_executable)
Update: If I don't add executable to Clion, I have an
error, that an executable is required.
Here my CMakeLists.txt.
This is an old question. But I'll add the answer to your question as a help for other people. You need to replace your add_executable with add_library
add_library(target_name source_files)
Short answer: compile the library target and run any custom command as a placeholder to avoid the warning.
Long answer:
CLion lets you either build the whole project and run executables/configurations.
When running executables, you can choose a target to compile and the executable to run after compiling the target. For executable targets, they are usually the same thing. You compile the executable target and then run it.
It seems like this is not really designed for libraries, but there is a workaround. You usually set the target to be the library and the executable to be any executable that depends on this library. However, this is usually not very useful because if you wanted to run this executable you could just set this executable to be the target and the library would be built anyway.
So people probably want to just build the library (to check if everything is OK, etc) without compiling or running any extra executable targets. In this case, the workaround is to choose a custom executable to run after building the library, and the error message is gone.
You have nothing useful you need to run after building the library, just choose any cheap command as a placeholder. Something like "pwd" or "ls".
It seems cmake can't determine which libraries can be used with the current compiler or rather I want cmake to only use libraries that have been compiled with the same compiler.
I am using find_library to find the needed libraries but it seems to be unable to determine if the library is actually usable. It managed to find the library by name but it was using the ".lib" extension when I was making a configuration for MinGW. Do I have to create folders for every compiler I compile libraries for and add if statements for each compiler in my script ? That just seems counter intuitive to what I believed find_library would be capable of. Perhaps I am misusing it ? Anyone have any better ideas ?
It seems you're a bit confused: you're right when you suggest that you need different libraries for MinGW and Visual Studio on Windows. But you're wrong when saying that .lib files can't be used by MinGW. Both Visual Studio and MinGW use .lib files to link to libraries on Windows.
The find_library command purpose is only to find libraries. Nothing more, so it's doing its job here.
If you want to make sure that the libraries found can be used by your compiler, you'll have to check that those libraries can be used by your compiler using try_compile:
find_library(YOURLIB_LIBRARY yourlib)
if (YOURLIB_LIBRARY)
try_compile(YOURLIB_WORKS
bindir
somefile.c
LINK_LIBRARIES ${YOURLIB_LIBRARY})
if (YOURLIB_WORKS)
# do something with your library
else()
# warn the user of stop the configuration process
endif()
endif()
I am trying to use vtune with my application compiled with mingw in Windows.
When I try to see souce code information, vtune says the is not line information in the resulting executable. I am compiling with -g option so I dont know where is the problem. So the questions are:
Is it possible to profile with a program compiled with mingw in windows? It looks like all is ready for MS-VC, but not for mingw.
If so, is it needed to change the object format (coff, xcoff, DWARF, ....)?
maybe if someone post an example it would be valuable.
Solved, compiled with
-gstabs -g3