I'm currently trying to compile dynamicaly linkable libraries, which would link during run-time with an application I'm writing.
I'm not sure how these libraries are called, so just to be sure : they're those libraries you load not during compilation, but during runtime using :
- dlopen / dlsync using libdl
- LoadLibrary / (another one with a complicated name) using Windows.
The thing is I can't find a CMake-way to compile those librairies under Windows : using Linux, this works perfectly :
set(libName myLib)
set(srcFiles myLib.cpp)
add_library(${libName} MODULE ${srcFiles})
Still, running Windows, it doesn't work at all : the Makefile is trying to link some pieces of code the myLib.cpp is referencing to (but it shouldn't... those symbols should be resolved at runtime).
I'm using the CodeBlocks MinGW generator if it may helps.
I think this would help:
add_library(${libname} SHARED ${srcfiles})
As CMake documentation says, MODULE should be used for building libraries that should be dynamically loaded using dlopen-like functionality. On Windows use SHARED instead of MODULE.
Related
Came across the following paragraph from a page on the MySQL website here:
You can write plugins in C or C++ (or another language that can use C
calling conventions). Plugins are loaded and unloaded dynamically, so
your operating system must support dynamic loading and you must have
compiled the calling application dynamically (not statically). For
server plugins, this means that mysqld must be compiled
dynamically.
What is meant by dynamical compiling? I know about dynamical linking, but I'm not sure what they meant with dynamical compiling.
Also, on Windows 10 (x64), how can I assure that an exe has been compiled dynamically? Is it possible to figure it out from the output of dumpbin? Here's the dumpbin output for mysqld.exe (version 5.7):
Note: I reviewed this old question which did not provide me with that much information. The depends tool it suggests is no longer on Windows.
Compiling dynamically simply means that you are compiling the code such that the compiled output is suitable for dynamic linking.
On Windows, the process of creating as DLL necessarily compiles it such that it's suitable for dynamic linking because DLLs are always dynamically linked.
I believe that most platforms today always compile dynamically and produce relocatable output, even if they're subsequently linked statically.
I am building Go code that uses CGo heavily and this code must be compiled into a shared or static library (static is highly preferred). (code for reference)
It all works just fine on Linux and Mac, but on Windows it fails on linker stage either saying that all 4 modes (c-shared, shared, c-archive, archive) are not available or if invoke go tool link -shared manually complains about missing windows specific instructions.
My understanding is that all I need to build usable lib.a is to compile everything I will use into object files (*.o) and then put it through ar to produce usable static library.
Now the question is whether I can completely skip Go's linker and based on prepared .o files create .a manually?
How would I go about doing that if that is even possible?
Looks like gcc on windows is unable to automatically discover necessary shared libraries. The problem was caused by GCC and not by Go.
Although for compiling Go I had to use self-compiled master tip as current release (1.6.2) does not support shared/static libraries on windows/amd64.
Manually feeding gcc with each shared library (ntdll, winmm etc) in default location (C:\Windows\SysWOW64) has fixed the problem.
I'm using the latest github version from https://github.com/bulletphysics/bullet3
To generate the visual studio solution, I've used the 'vs2010.bat' located in bullet3/build3. This sets it up as static libraries however. If I change the configuration type to dynamic, the .dlls are generated properly, but no .lib-files.
I've also tried using CMake with "BUILD_SHARED_LIBS" enabled, but again, no .lib-files are generated.
What's the proper way of building bullet as shared libraries?
At the moment it is not possible using Visual Studio on Windows to generate import libs (.lib) when using shared libraries for Bullet. The reasons is that no symbols are explicitly exported. Shared libraries work fine using gcc or clang on Linux and Mac OSX. It would require quite a bit of work to instrument the code to fix this issue.
See also https://cmake.org/Wiki/BuildingWinDLL
We have a software project which has the primary purpose of providing a library and API. We also provide example programs and utilities that use this library.
So, let's say that I have built and installed our library. When I run valgrind on one of the example / utility programs, I obviously see references to functions in the library. The issue is that it doesn't provide line numbers, and I would like it to.
Is there a way to tell Valgrind to reference source files that aren't obviously part of an executable, but are part of the source code for a library that is linked-in to the executable?
Thanks!
Make sure that you are compiling shared library with -g to add debug information. This should be enough for Valgrind to reference source files. See http://valgrind.org/docs/manual/faq.html#faq.unhelpful for more information.
First, I am sorry about my English. That's not my language.
I am developing an application in QtCreator, Linux. When the IDE asked me about the libraries I would use, I just leave the selected ones (they was not enabled for unchecking). Now, I have to run the compiled file in RedHat 5, but it doesn't run. It tells "Error while loading shared libraries: libQtGui.so.4: ...". So, how do I fix this problem?
I should not install Qt libraries in RedHat (it's a server). I prefer to compile the Qt project including needed Qt libraries (into self compiled file, or in the same directory).
Please, can you tell me some idea??
If you cannot install qt you have two main alternatives:
Deploy the libraries together with your application (how you do this depends on the way you deploy your application. It may suffice to do a manual copy.)
Statically link with the qt libraries. They will then be included in your executable (which will be much larger as a result). Static linking
Some pros and cons of static vs dynamic linking are discussed in this thread.