I'm building a dll in D with some utils, tools, ect. I can successfully compile a basic dll and test program to use it in visual D without any issues. I am familiar with the process of creating and using dll's. Especially statically linking against them. But if a module in the dll has a static this(), or imports a module with a static this(), the dll will compile, but any program you build that uses it will fail with a foo.bar.__ModuleInfo being unresolved.
error LNK2001: unresolved external symbol "dtoolbox.dtoolboxdllmain.__ModuleInfo" (__D8dtoolbox15dtoolboxdllmain12__ModuleInfoZ)
In this case my dllmain module dtoolbox.dtoolboxdllmain imports core.runtime which has a static this() so i get this error. How do i resolve this? What are static module constructors doing to cause this? As long as there are no static constructors everything works fine.
[edit] Importing core.runtime wasn't the problem, it was the modules own static this(), not core.runtime's static this().
The solution is to refrain from importing a module with the dll's static this() && static ~this() into a module of a program which uses the dll. (In this case the dllmain module was being imported, for no reason at all, my mistake) Not to say that the dll can not have them though, they just need to be there in some file when compiling the dll. I found it convenient to write them in the same module as your dllmain as this file will never really need to be referenced/imported by a program using the dll.
Related
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've workspace with two project: static lib and cocoa application. Static library link some system frameworks(libcrypto.dylib) and include dynamic lib's .h files(openssl/bn.h openssl/rsa.h). My static library compiles successfully.
Cocoa application uses this static library and at compile time gives an error: "undefined symbols, symbols not found" (bn, new rsa etc).
But when I include libcrypto.dylib also into cocoa application project then there is no error.
Question: Xcode can do this automatically, by taking dependency from the static link library?
Thanks.
The answer is unfortunately no. It is common practice to include each single static library in the project that requires the code. That is just the way it is done.
There is an interesting article on how to handle multiple static libraries in an XCode project.
I am using Visual Studio 2008 trying to create a .dll. The dll uses an external library (.lib). Compiling and linking works fine (I included the paths to header/lib in the options). When my .dll is used by a program (as a plugin) it says "externalLibrary.dll missing" but there is no externalLibrary.dll, just a externalLibrary.lib.
Are there different options of linking (so the externalLibrary is already in my .dll)? Or can i simply create a .dll from the .lib? Or any other solutions to this problem?
Edit (to be more concrete):
In project properties i added
the header path # C/C++ - General - Additional Include Directories
the library path # Linker - General - Additional Library Directories
the library name # Linker - Input - Additional Dependencies (although
this doesn't change anything)
The .lib file you are using is an import library which basically means that it contains only stubs for functions/classes/... but not the actual implmentation. That implementation is in the dll. An import library is only useful for the linker as it uses it to resolve symbols. But at runtime, the actual compiled code is needed so your application/dll looks for the dll. But even if your dll is used as a plugin, it's no problem for it to depend on other dlls. So if you have the other dll I suggest you go that way. (what is 'externalLibrary' btw?, it's not normal a vendor supplies you only with an import library and not the dll)
If you really do not want to use the external dll, you'll have to find the static library for the code of 'externalLibrary'. Unlike the import library, a static library does contain all symbols complete with actual implementation etc. So after linking with a static library, your application/dll contains the code itself and does not need to resolve it at runtime.
I have a DLL that I am trying to link with a libjpeg LIB using MSVC 2008 that is generating Unresolved External Symbol errors for the libjpeg functions. I also have a test project that links with the exact same libjpeg library file and links without error and runs fine too.
I have triple-checked my LIB path and dependent LIBS list settings and literally copy and pasted them from the EXE project to the DLL project. I still get the errors. I do have the libjpeg include headers surrounded by extern "C" so it is not a name mangling issue and the unresolved external warnings show the "missing" libjpeg functions as undecorated (just a leading underscore and the # sign parameter byte count suffix after each name).
What could make the linker with the DLL project be unable to find the functions properly when the test EXE project has no trouble at all? I'm using the pre-compiled 32-bit static multi-threaded debug library which I downloaded from ClanLib.
Thanks,
Robert
After a lot of experimentation I found the solution. It turns out the problem was due to a difference in the calling convention used by the DLL and the LIB projects (In MSVC 2008 this is set on the Project Properties, "Configuration Properties -> C/C++ -> Advanced" setting. The DLL project was set to __stdcall and the LIB was __cdecl. Recompiling LIBJPEG with __stdcall fixed the problem.
What is the difference between Load-time dynamic linking and Run-time dynamic linking?
Load-time Dynamic Linking
When an executable is linked to a DLL at build time the linker will not insert object code but rather it insert a stub which basically says a function of this name is located in this DLL.
Now when the executable is run, bits of the executable will be missing (i.e the function stubs) so before the program is allowed to run the program loader fixes up these missing functions by replacing them with entry points into the DLL files.
Only after all the stubs have been replace (i.e resolved) will the executable be allowed to run.
That is load time dynamic linking.
Run-time Dynamic Linking
In this case the executable was not linked to any DLL library file, so it will not contain any stubs into the dll and as such the program loader has no issue running the executable.
But the task of getting access to the function from with-in the DLL is left to the executable and can be done using the GetProcAddress Windows API.
That is run time dynamic linking.
You forgot the "homework" tag.
Load-time linking means that the DLL you're linking to is loaded when your application starts, regardless of whether or not you actually use the functionality in that DLL. Dynamic linking means that the functionality of the DLL is only loaded when it's actually needed.
Load time dynamic linking is performed by Operating System when an application is loaded. OS uses the information linker has placed in the file to locate the names of the dll, and then searches for those dlls, And if it fails to locate the Dll, it simply terminates and gives error message, otherwise, OS maps the DLL into the virtual address space of the process and increases the DLL reference count.