Is it possible (or relevant at all) to export member functions of a static library?
When I "dumpbin /EXPORTS" my .lib file I don't see any of my defined class members.
Linking to this lib file succeeds, but I use an external tool that fails to read non-exported symbols.
Also tried adding a .def file with no results.
A static library is just a collection of .o files. This is then linked into your executable in exactly the same way as .o files so whatever works for .o files will work for static libraries.
Related
I'm working on Xcode project where I have a static library that is linked to another library which i compile with flag -DMODULE in "other C Flags (see images) .
However, during execution when I reach one of the static library functions, the MODULE doesn't defined anymore, any idea why ?
Static library is linked prior to runtime, and composed from a bunch of .o files, so i would assume those are having the same treatment as any other .o file in the parent library that the flag applies to. Am i missing something ?
Compiler defines are applied during the conversion from source to object (.o). A static library is just a bunch of .o files glued together. If you already have a static library, you can't apply defines to it anymore. If you need to change the defines, you'll need to recompile the source rather than using a static library.
Remember that compiler defines are applied by the pre-processor. They replace part of the source code text with some other text. They're applied before the compiler even sees the code (let alone the linker).
I'm using a Facade DLL to a static lib. The Dll provides a small interface and resource management to be shared across multiple DLLs. The Dll-Header do expose stuff from the static library:
class DLL_EXPORT MyDllClass {
public:
/// ...
OneStaticLibClass * ptr;
};
The Problem is: if this should works I've to link the StaticLib to the DLL and the application using DLL. I didn't manage to export parts of the StaticLib correctly. I tried in the export headers:
class DLL_EXPORT OneStaticLibClass;
but that doesn't work... I still get:
undefined reference to OneStaticLibClass::~OneStaticLibClass(void)
undefined reference to OneStaticLibClass::operator<<(char const *)
Andy ideas how I can export parts of the static library with the DLL?
Thank you!
You will need to create a .def file and pass it to the linker. DLLEXPORT is not necessary in this case.
The reason for this is the way symbols are resolved when using a static library. When you create a DLL, only those symbols needed by the DLL itself are searched, and object files containing these symbols are copied into the DLL. If the DLL code does not reference your destructor, it will not be included.
A .def file will tell the linker which functions are exported. Exported functions will be searched and pulled from the static library.
One downside of this process is that you need to use mangled C++ names in the .def file. Mangled names can be obtained with the dumpbin utility.
I have a bunch of cpp files (there should be no header files) that contain static variables. These static variables seem to be ignored by my Visual studio 2008 compiler - how can I fix it?
More details:
I have an abstract class that has a static field allInstances; when an "concretee" instance of my class is constructed (it happens when static variables that sit in cpp files are instantiated), a pointer to it is push_back'ed into allInstances.
Cpp files contain the classes derived from my abstract class; their implementations need to stay in cpp files as they are only meant to be called through allInstances
My abstract class cpp files sit in a folder (project) that compiles in a static library
This static library is used by a project that compiles an xll
When cpp files were sitting in xll project, everything was fine. But when I moved cpp files in a separate folder (needed to be done because excel is now not the only interface) my static variables are no longer instantiated.
I have a lot of these cpp files and including all of them into each of xll, exe, pyd, dll, etc. projects would not be nice....
Any ideas?
Many thanks in advance.
You have to tell the linker that the corresponding object files are part of the program. Typically, this is done by specifying them as object files, rather than by putting them in a library; by definition, object files in a library only become part of the program if they resolve an external reference.
How do you merge multiple static linked libraries into a single dll given each static lib defines exported functionality (vc++ 2008)?.
In a multi project layout existing out of a single dll project and multiple sub projects that are linked in statically (in the dll project). Despite being marked as __declspec(export) some of the symbols in the sub-projects (.lib) refuse to have their symbols exported in the final dll.
Generating a .def file and marking the symbols explicitly for exportation could solve this problem. However identifying which of the symbols are marked as __declspec( export ) proofs a problem. Due large number of exported classes/function and primarily name mangling maintaining a list by hand is a unfordable process thus generating the list of symbols, that were marked for export, would be the only viable option.
Is there an utility or compiler directive could do this?
Use a DEF file.
Always use a DEF file.
Never fail to use a DEF file.
Just accept that a DEF file is the thing to use.
Stop using __declspec(dllexport), and use a dang-dratted def file already.
Also don't export classes. Export those class members which need to be exported only. And use a DEF file to do it.
Seriously, if you export classes without a DEF file, the function names will be several times longer than the actual program data. You should to use ordinals for exporting C++ member functions.
After bit trial and error I found that using the lib /def command can be utilized to generate an import library and export file. It appears that the export file contains all symbols that are marked with __declspec(dllexport). Subsequently the .exp file can be inspected with dumpbin and used as a reference to generate a module definition file.
Starting with Visual Studio 2015 Update 2 there is a new way of doing this, by using the linker option /WHOLEARCHIVE
It's documented here
The /WHOLEARCHIVE option forces the linker to include every object
file from either a specified static library, or if no library is
specified, from all static libraries specified to the LINK command. To
specify the /WHOLEARCHIVE option for multiple libraries, you can use
more than one /WHOLEARCHIVE switch on the linker command line. By
default, the linker includes object files in the linked output only if
they export symbols referenced by other object files in the
executable. The /WHOLEARCHIVE option makes the linker treat all object
files archived in a static library as if they were specified
individually on the linker command line.
In a c++ project I am working on, I have a simple c++ file that needs to run some code at the beginning of the program execution. This file is linked into a static library, which is then linked into the main program.
I have similar code in other files running fine, that looks something like:
bool ____nonexistent_value = executeAction();
However, it does not work inside this file unless I make use of a function implemented in this file. It does work if the library is compiled as a shared library. I'd prefer to link this statically as the library is only a convenience as the file is in a different directory.
Update (Solution):
For now creating shared instead of static libraries makes everything work. Later I will look into getting everything linking with static libraries. Thanks for everyone's help!
If no symbol is referenced in that particular file then the file will not be included by the linker. You have two options:
Remove the file from library and include it (object or source file) directly in the command line for compilation/linking. Then the file should be included in executable.
Have a symbol in a file which you reference from from other files (for example the one with main() definition), this should "pull" the file during linking.
I'm not sure if there's a way to guarantee such static allocation in a static library, but you can always make it explicit. Provide an init function for your library that will be called from main to setup everything you need. This way you don't have to worry about linkers omitting code that's apparently unused, etc.
There's no guaranteed order for static initialization. You want to be very careful with this!