Is it possible to convert MAVLink C library to .so using eclipse?
I'm trying to call mavlink library from lunix RT on myRio1900 board.
MAVLink is a header-only library: a bunch of typedefs and macros scattered in header files. No need to compile and link, just include and use it.
Related
I am trying to convert this https://github.com/OpenEtherCATsociety/SOEM library into a dll in order to import it in labview.Can i turn this library into a DLL?And how? Thank you!
If you want to configure CMake to build a .dll, instead of a .lib, you have to edit the top-level CMakeLists.txt file from the SOEM repository. Instead of a STATIC library, we want a SHARED library, so change this:
add_library(soem STATIC
${SOEM_SOURCES}
${OSAL_SOURCES}
${OSHW_SOURCES}
${OSHW_EXTRA_SOURCES})
to this:
add_library(soem SHARED
${SOEM_SOURCES}
${OSAL_SOURCES}
${OSHW_SOURCES}
${OSHW_EXTRA_SOURCES})
Now, re-run nmake (which will re-run CMake as well), and a DLL will be built instead.
I am a question about dll use in linux. I have dll and .h file that work good in windows. But now I need to work this program in linux. If I write a .cpp file that
function call the dll file's function. Could I compiler this .cpp file to assembly or to .so file. Then I can use .so file without original dll file ?
If you have a DLL that builds on Windows, then provided the C++ code is portable, it should be possible to compile the same code on Linux to produce a shared library (.so file), which is Linux's equivalent to Windows DLLs. There is good background on this topic here.
If your source code (i.e. CPP or header files) uses #include for headers that are Windows-specific, you will have to make that code portable in order for Linux to build and run it. One approach is to just try compiling your code on Linux and see what errors arise. If you want to be more proactive, for C++ portability guidelines see here.
I have legacy c++ code that I'm trying to re-engineer.
I want to take some part of code out of the project as a ".so" shared library and load them dynamically by "dlopen".
I have written a dynamic loading mechanism which can load new modules dynamically at runtime.
Now I want to decouple existing modules from main project.
For instance I have extracted module "X" from the main project and created shared library which can be loaded later, but some part of the main project are using module X's classes directly and I can't change them yet.
I can compile the project by using module X's header files, but linker throw out "undefined reference" error.
How can I tell c++ linker that these classes will be added later by dlopen mechanism at runtime?
note: I can link and run project by copying created ".so" file of module X in "/lib" folder and use it when linking by "-lX" flag, but if I delete this file form the /lib folder the project fails on startup.
I know if you use X's classes directly you have to link X.so to your program. But if you link X.so you can use dlopen in runtime.
What you need is called an import library. They contain small wrappers for all necessary functions and thus satisfy all static linker dependencies. At runtime these wrappers will load dynamic library if it's not yet loaded and forward execution to real implementation inside library.
Import libraries is a standard feature of Windows DLLs but they are not available out-of-the-box on Linux (or any POSIX system). You can implement wrappers by hand or use Implib.so to generate them automatically.
I have a project that has a bunch of .c files that need to be compiled as C files, but I need one of them to be compiled as C++ code.
I tried the solution found here but it did not work as expected. Instead of making only filename.c be compiled as C++, it compiles all the files in my project as C++ code. Without that call, all files are compiled as C.
I even tried this:
set_source_files_properties(${FILES_SRC} PROPERTIES LANGUAGE C)
set_source_files_properties(filename.c PROPERTIES LANGUAGE CXX)
Where the FILES_SRC variable holds all my source files.
I am using CMake 2.8.12 and the Visual Studio 11 ARM generator.
Any idea how I could fix this?
I ended up compiling the library using the C compiler and added the C++ code in a separate library for which I created a C interface so it can be called from my C library.
I am trying to use GLM to load a .obj object in my Objective-C Program (Xcode 4.4 Mac Os X). I have added the glm folder to my project. i try to import it using #import "glm/glm.hpp", but the program doesn't build. some of the errors are the following: (this errors are produced in the GLM files)
namespace glm{ //Unknown type name 'namespace'
namespace detail
{ .....
It doesn't find the cstdlib, cmath, and other libraries.
This happens because my program is in Objective-c and the GLM doesn't work with this language?
Those are all symptoms of trying to compile a C++ application with a C compiler. Namespace is a C++ keyword, and cstdlib, cmath, etc. are C++ names for standard C headers. You'll have to migrate your project to Objective-C++ to be able to use GLM.
Any files that uses the GLM library will require that file extensions to be renamed to .mm as it uses Objective-C++. Also, as it is only a file, and not a framework, you only need to put #import "glm.hpp"