I'm New to CLion. I have created a project which name is test12 and which file name is avs.c.
I'm Getting an Error of type Undefined reference 'sqrt'
CMakeListsta.txt is :
cmake_minimum_required(VERSION 3.13)
project (test12 C)
set(CMAKE_C_STANDARD 99)
add_executable(test12 avs.c)
What changes should I do to make CMAKELISTS use math.h header in CLion?
It looks like math.his not enabled in CLion, so you need to enable it! Source here.
add #include <math.h>
add target_link_libraries( m) in CMakeLists.txt
The second command allows you to link with libm for the math functions.
Adding this to your makefile! (Check the source I gave you!!)
target_link_libraries(log m)
Related
I would like to use wxWidgets 3.0.2 library in my project. However I am unable to run even the hello world program. I have downloaded the headers and the appropriate binaries (TDM GCC x64 4.8.1). I've extracted them without any changes. So there are include and libs folders present in my wxWidgets folder. I am using TDM-GCC 5.1 which is setup properly.
When I create a simple console application and only include the main file
#include "C:\wxWidgets\include\wx\wx.h"
I get an error
C:\wxWidgets\include\wx\wx.h|14|fatal error: wx/defs.h: No such file or directory|
Which is quite reasonable, as defs.h is in the same folder as wx.h and there is no wx folder inside. Do I need to rearrange the file structure?
Is the compiler problem here (5.1 used instead of 4.8.1)?
For three days I am running trough different tutorials, and all the time I get this or similar errors. How to set it up properly?
The whole code is just:
#include <iostream>
using namespace std;
#include "C:\wxWidgets\include\wx\wx.h"
int main()
{
cout << "hello" << endl;
return 0;
}
You should never include wxWidgets (or any other library) header files using full paths. Instead you should have just
#include <wx/wx.h>
in your code and set up your compiler headers search path to include c:\wxWidgets\include directory. Notice that you will also need to add c:\wxWidgets\lib\gcc481_lib\mswu or similar to the includes path, depending on the exactl configuration you're using (e.g. it could be gcc481_dll if you're using the DLL build).
I am creating a small command line C/C++ app to convert a binary file to a tab delimited text file after not working with C/C++ for several years. Netbeans is new to me as well. The include files below work fine when I build using 'Debug' but when using 'Release' I get the IDE error "Cannot find include file'; The files are flagged as well as lines of code. The compiler error is 'No such file or directory'.
I have other apps in the work space that do compile with the release tab set.
// these are the first code lines in the file
#include <cstdlib>
#include <iostream>
#include <fstream>
#include <string>
// No problem with these
#include <math.h>
#include <stdbool.h>
I don't notice any differences in properties between the apps that build correctly and this one.
Edit:
I've added the path to the includes, /usr/include for C and /usr/include/c++/4.9.2/ for C++, (I have not done this for other apps and they compile) and the error colors for the release includes went from red to yellow and only two lines in the code had red underlines. size_type and npos with the error "unable to find identifiers:
void replaceExt(std::string& s, const std::string& newExt) {
std::string::size_type i = s.rfind('.', s.length()); // size_type
if (i != std::string::npos) { //npos
s.replace(i + 1, newExt.length(), newExt);
}
}
The compiler produced this error message:
gcc -m64 -c -g -I/usr/include/c++/4.9.2 -I/usr/include -MMD -MP -MF "build/Release/GNU-Linux-x86/main.o.d" -o build/Release/GNU-Linux-x86/main.o main.c
In file included from main.c:9:0:
/usr/include/c++/4.9.2/cstdlib:41:28: fatal error: bits/c++config.h: No such file or directory
#include <bits/c++config.h>
Final Edit
It didn't appear right that NetBeans would not have the path to the standard includes so I created a new C++ project, accepted all the default preferences, and copied the all the code except main from the failed project to the new one checking to see if it would compile. Lastly I copied main and found that it builds in both release and debug with no errors.
I don't have any idea what went wrong, but I've found the fix.
It didn't appear right that NetBeans would not have the path to the standard includes so I created a new C++ project, accepted all the default preferences, and copied the all the code except main from the failed project to the new one checking to see if it would compile. Lastly I copied main and found that it builds in both release and debug with no errors.
I don't have any idea what went wrong, but I've found the fix.
There are three files, (m.c,m.h, and **main.c*).
File m.h
// m.h
int m();
File m.c
// m.c
#include <stdio.h>
#include "m.h"
int m(){
printf("Hello,m!\n");
return 0;
}
File main.c
// main.c
#include "m.h"
int main(){
return m();
}
While I prefer a shared library (m.dll), I've made the CMakeLists.txt file:
PROJECT("app1")
ADD_LIBRARY(m SHARED m.c)
ADD_EXECUTABLE(myexe main.c)
TARGET_LINK_LIBRARIES(myexe m)
The CMake configuration is done and generated done. Opening app1.sln and building with Visual Studio, it crashes as
LNK1104:Can't open file "Debug\m.lib"
It only works as STATIC at ADD_LIBRARY(). Why doesn't it work on Windows?
If I got another shared library (mylib.dll), how could I invoke its functions in my main.c and CMakeLists.txt files?
There are differences between dynamic library linking on different platforms which also needs some additional code. The good news is, that CMake can help you with this. I found the following blog post by Gernot Klingler very useful:
Creating and using shared libraries with different compilers on different operating systems
In short you need some "export prefix" defined for whatever is declared in m.h. Otherwise the build process will not generate an "import library" for statically linking named m.lib (see also CMAKE_IMPORT_LIBRARY_SUFFIX).
Here is your code with the modifications needed:
m.h
#include "m_exports.h"
int M_EXPORTS m();
m.c
#include "m.h"
#include <stdio.h>
int m(){
printf("Hello,m!\n");
return 0;
}
CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
include(GenerateExportHeader)
PROJECT("app1")
INCLUDE_DIRECTORIES("${CMAKE_CURRENT_BINARY_DIR}")
ADD_LIBRARY(m SHARED m.c m.h m_exports.h)
GENERATE_EXPORT_HEADER(m
BASE_NAME m
EXPORT_MACRO_NAME M_EXPORTS
EXPORT_FILE_NAME m_exports.h
STATIC_DEFINE SHARED_EXPORTS_BUILT_AS_STATIC)
ADD_EXECUTABLE(myexe main.c)
TARGET_LINK_LIBRARIES(myexe m)
Additional References
GenerateExportHeader macro
cmake and GenerateExportHeader
How do I get CMake to create a dll and its matching lib file?
MSDN: Walkthrough: Creating and Using a Dynamic Link Library (C++)
Using WINDOWS_EXPORT_ALL_SYMBOLS might help. See an introductory article for details. In short, invoke CMake like this:
cmake -DCMAKE_WINDOWS_EXPORT_ALL_SYMBOLS=TRUE -DBUILD_SHARED_LIBS=TRUE
Add this in CMakeLists.txt.
if(MSVC)
set(CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS TRUE)
set(BUILD_SHARED_LIBS TRUE)
endif()
Trying to figure out how to use BGL from within Objective-C++. Something is amiss. Steps to repro:
New Cocoa Application project.
Rename MyAppDelegate.m to MyAppDelegate.mm
Add #include <boost/shared_ptr.hpp> to MyAppDelegate.mm (works fine, assuming you have your header search paths set right.)
Add #include <boost/graph/adjacency_list.hpp> to MyAppDelegate.mm
Something transitively included by boost/graph/adjacency_list.hpp is colliding with some old Carbon headers that are being transitively imported by the Cocoa headers. Here is the output I see (the first error's worth anyway):
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:10:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/adjacency_list.hpp:33:
In file included from /Users/me/Documents/Projects/BoostTest/boost/graph/graph_traits.hpp:27:
In file included from /Users/me/Documents/Projects/BoostTest/boost/pending/property.hpp:13:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits.hpp:35:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_operator.hpp:12:
In file included from /Users/me/Documents/Projects/BoostTest/boost/type_traits/has_bit_and.hpp:43:
/Users/me/Documents/Projects/BoostTest/boost/type_traits/detail/has_binary_operator.hpp:154:42: error: expected member name or ';' after declaration specifiers
static ::boost::type_traits::yes_type check(has_operator); // this version is preferred when operator exists
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ^
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.mm:9:
In file included from /Users/me/Documents/Projects/BoostTest/BoostTest/MyAppDelegate.h:9:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:76:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:23:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/AE.framework/Headers/AE.h:20:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/CarbonCore.h:115:
In file included from /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Debugging.h:212:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:1291:28: note: expanded from macro 'check'
#define check(assertion) __Check(assertion)
^
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/include/AssertMacros.h:280:5: note: expanded from macro '__Check'
do \
^
If I remove the #import <Cocoa/Cocoa.h> from the project's prefix header, and then #include <boost/graph/adjacency_list.hpp> before including <Cocoa/Cocoa.h> in MyAppDelegate.mm things will compile, but this is sub-optimal/undesirable.
Is there something simple I can do (ideally in the prefix header so I don't have to do this everywhere) to make the Cocoa headers and the BGL headers co-exist peacefully?
Should have googled for epsilon more time before asking. Just after posting this I found this page which explains that adding the following line prior to including the Cocoa headers will do the trick:
#define __ASSERT_MACROS_DEFINE_VERSIONS_WITHOUT_UNDERSCORES 0
I had tried doing that in my individual MyAppDelegate.mm file, and it didn't work, but that was because of the prefix header. Adding it to the project's prefix header prior to its inclusion of Cocoa/Cocoa.h did the trick.
I'm using CMake to build a shared library, however for the Windows DLL I need the versioning information, like:
FileDescription
FileVersion
InternalName
LegalCopyright
OriginalFilename
ProductName
ProductVersion
So far, all I have are the VERSION and SOVERSION properties, but these don't seem to correlate to the FileVersion information I was expecting.
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} )
SET_TARGET_PROPERTIES(${LIC_TARGET}
PROPERTIES
VERSION ${MY_PRODUCT_NUMBER}.${MY_PRODUCT_VERSION}.${MY_BUILD_NUMBER}
SOVERSION ${MY_PRODUCT_NUMBER})
I've found manual methods (see example at the bottom) but would prefer to contain this within CMake.
Help?
You could use your CMake variable values in conjunction with a version.rc.in file and the configure_file command.
// version.rc.in
#define VER_FILEVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_FILEVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#.0\0"
#define VER_PRODUCTVERSION #MY_PRODUCT_NUMBER#,#MY_PRODUCT_VERSION#,#MY_BUILD_NUMBER#,0
#define VER_PRODUCTVERSION_STR "#MY_PRODUCT_NUMBER#.#MY_PRODUCT_VERSION#.#MY_BUILD_NUMBER#\0"
//
// ...along with the rest of the file from your "manual methods" reference
And then, in your CMakeLists.txt file:
# CMakeLists.txt
set(MY_PRODUCT_NUMBER 3)
set(MY_PRODUCT_VERSION 5)
set(MY_BUILD_NUMBER 49)
configure_file(
${CMAKE_CURRENT_SOURCE_DIR}/version.rc.in
${CMAKE_CURRENT_BINARY_DIR}/version.rc
#ONLY)
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES}
${CMAKE_CURRENT_BINARY_DIR}/version.rc)
# Alternatively you could simply include version.rc in another rc file
# if there already is one in one of the files in ${SOURCES}
I'm had same problem and have automated version generation for my projects.
You need three files from github:
generate_product_version.cmake
VersionInfo.in
VersionResource.rc
Put it in cmake subdirectory of your project and make sure to include it to CMAKE_MODULE_PATH like:
set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} ${CMAKE_SOURCE_DIR}/cmake)
Then before add_executable() or add_library(SHARED) your target, use:
include(generate_product_version)
generate_product_version(
VersionFilesOutputVariable
NAME "My Great Project"
ICON ${PATH_TO_APPLICATION_ICON}
VERSION_MAJOR 1
VERSION_MINOR 3
VERSION_PATCH ${BUILD_COUNTER}
VERSION_REVISION ${BUILD_REVISION}
)
Full list of supported resource strings see in generate_product_version.cmake.
VersionInfo.h and VersionResource.rc will be generated to cmake binaries folder. Variable VersionFilesOutputVariable will hold paths to these files. Just add this list to your target:
add_executable(MyGreatProject ${your-target-sources} ${VersionFilesOutputVariable})
UPDATE: Corrected generate_product_version script parameters from VERSION_PATH
to VERSION_PATCH.
There is an even easier way than the accepted answer. It does not involve transforming an input resource.rc.in. Simply create a generic version.rc file as described here and then from your CMakeLists.txt do this:
#CMakeLists.txt
add_definitions(-DVER_COMPANYNAME_STR="MyCompany")
add_definitions(-DVER_FILEVERSION_STR="1,1,0.0")
# ...
# add all the other defines here
set(LIC_TARGET MySharedLib)
add_library(${LIC_TARGET} SHARED ${SOURCES} version.rc)
This has the added benefit that the defines are accessible from your source code as well, so you have programmatic access to your version.