unknown type name '_declspec' on cmake - cmake

I am trying to generate a shared native library using cmake. the contents of this library are nothing more than native functions that will later be used in Unity. that is why the functions have the extension __declspec (dllexport) so that in the Unity section they can be called with dllImport.
My problem comes when I try to compile that library in cmake. I am using Ninja as compiled and cross-compiled with Android toolchain. The problem is that it tells me:
../InnovaeInterface/include/Camara.h:7:2: error: unknown type name '_declspec'
_declspec(dllexport) CameraUtils::Calibration* createCamara(void);
^
../InnovaeInterface/include/Camara.h:7:22: error: expected ';' after top level declarator
_declspec(dllexport) CameraUtils::Calibration* createCamara(void);
^
The truth is that I have no idea where to throw. I hope you help me.

Related

Switch between Debug and Release Library in cmake programmatically for vcpkg installed libraries

I have successfully compiled my C++ program but I am a getting linker error
(default)\Catch2.lib(catch_stringref.cpp.obj) : error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in main.cpp.obj
After reading the post I realized this is due to improper library selection by library (using release mode library while my application is in debug mode) hence I printed the path to catch2 library
CMake Code
find_library(CATCH2_LIBRARY catch2)
message ("CATCH2_LIBRARY : ${CATCH2_LIBRARY}")
target_link_libraries(${PROJECT_NAME} ${CATCH2_LIBRARY})
returned
CATCH2_LIBRARY : D:/vcpkg/installed/x64-windows/lib/Catch2.lib
instead of
D:/vcpkg/installed/x64-windows/debug/lib/Catch2d.lib
I wish to know how can I make the cmake look into the debug directory (for libraries) when I am building in debug mode and vice versa.
Kindly note in Debug Mode the library is Catch2d.lib and in release mode it is Catch2.lib.
Library Paths
Release Library Path : D:\vcpkg\installed\x64-windows\lib\Catch2.lib
Debug Library Path : D:\vcpkg\installed\x64-windows\debug\lib\Catch2d.lib
This is continuation of my first cmake usage saga carried forward from here
What you are most likely interested in, is something that's called a generator expression. This allows you to define specific flags/names/suffixes/prefixes etc. based on the specified configuration.
They usually look something like this:
target_link_libraries(foobar PRIVATE Catch2$<$<CONFIG:Debug>:d>)
When running cmake with the Debug configuration it will add a d at the end of Catch2

Unrecognized option "--enable-new-dtags" error during building c++ library

During building a c++ source code (configured with cmake gui) with mingw under MSYS gives following error while trying to "Linking C shared library":
Unrecognized option "--enable-new-dtags"
How can i solve this issue?
Likely --enable-new-dtags is supported only on ELF targets. For example there's a patch for Python3 distutils which sets this flag conditionally on the target platform: https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-python3/0260-MINGW-compiler-enable-new-dtags.patch . You should make sure that this flag isn't specified explicitly somewhere in your project.

error related to static linking of glibcxx and glibc

I am am trying to cross-compile an x86 program for alpha using g++. For that, I tried both "-static-libgcc" and "--static" options when linking the object file with libraries to generate the binaries. The cross compilation was successful, however I got the following errors when I ran the binaries on alpha machine:
./word_count: /lib/libc.so.6.1: version GLIBC_2.4' not found (required by ./word_count)
./word_count: /usr/lib/libstdc++.so.6: versionGLIBCXX_3.4.10' not found (required by ./word_
These errors shouldn't happen, since I am using static linking! So, I cannot figure out why I am getting these errors! Any help is appreciated.
You need to link against both, standard C and C++ libraries. (source)

VS10 always links to SUBSYSTEM:WINDOWS; CMake+SDL+GLEW

I'm just trying to set up a simple project that shall be able to compile on every platform, that is supported by CMake. I started my project on a Win7-system and wrote a little main.cpp that includes SDL.h and GL/glew.h. The style of the main-function is simple c++:
int main(int, char**) {}
In my CMakeLists.txt I call find_package(SDL) and find_package(GLEW). The CMake-part works well, so I just opened the vs10-solution-file and tried to compile when I get the LNK2019:
error LNK2019: unresolved external symbol main referenced in function __tmainCRTStartup
This would mean that I chose the wrong subsystem, doesn't it? But if I simply toggle the subsystem from CONSOLE to WINDOWS and back the problem still exists. Has CMake set a hidden option for that? How can I compile my simple program in vs10?
I had this problem tonight. I'm using CMake to create an MSVC project to build my GLFW app. Of course, the age-old trick for getting rid of the console window if you're using MSVC by itself is to go in to the properties and set "Subsystem" to "Windows" and "Entry Point" to mainCRTStartup, which corresponds to adding the /SUBSYSTEM:WINDOWS /ENTRY:"mainCRTStartup" flags to link.exe, but CMake doesn't provide an easy way to do that.
If you just do a straight-up add_executable() command, you'll get /SUBSYSTEM:CONSOLE /ENTRY:"mainCRTStartup" being passed to the linker.
If you do an add_executable(exename WIN32 ...), you'll get /SUBSYSTEM:WINDOWS.
Gaah! Either option gets us halfway there!
I poked through the .cmake files that CMake ships with (fwiw, I'm using CMake 2.8.10 and Visual Studio 2012 Express), and discovered that the variable that seems to control the /SUBSYSTEM and /ENTRY flags is called CMAKE_CREATE_WIN32_EXE. So to set both parts, we just have to change that variable. Here's what I ended up with, which did the trick:
if(MSVC)
set(CMAKE_CREATE_WIN32_EXE "/SUBSYSTEM:WINDOWS /ENTRY:\"mainCRTStartup\"")
endif(MSVC)
Hope that helps someone else.

Dynamic loading and symbols sharing

I'm trying to load a module library via dl in such way, that the module can access globals from the main application. How is that possible to do?
I get an error message from dlopen saying library/name.so: undefined symbol: .... The only flag used is: RTLD_NOW.
The module itself is build with libtool with -module -avoid-version.
The answer is: use -Wl,--export-dynamic when linking the main binary, so all symbols are automatically exported to the loaded libraries.
Same question, just asked differently: Receive "undefined symbol" error when loading library with dlopen