Question

Is there, a perhaps undocumented way to prevent linker from creating IMPLIB for a DLL or an EXE, despite having __declspec(dllexport) directives within the source code?

Specifying no /IMPLIB results in .LIB created with a default name.

This is important when the declspec directives arrive from 3rd party code which is not under control. This is, for example, the case with boost::serialization. A possible solution would be a way to "undeclare" a DLL export. DEF file also cannot do it (AFAIK), because it can only add to the export list but not remove from it.

Was it helpful?

Solution

Many 3rd party code does not use __declspec(dllexport) directly, but hides it under a macro in order to control it. Typically they want to switch between dllexport and dllimport depending on where the header file is included (inside the dll implementation or by the user of the dll)

If that is the case in the library you try to include it should not be too difficult to alter this behavior via macro manipulation to meet your exact needs.

For example, boost::serialization check the config.hpp and see how you can control it.

OTHER TIPS

According to this, if you supply the .exp file when linking, the linker will not create a .lib file. To be honest, though, I can't tell if this helps in your case.

There is not any way to do this with a linker option, using /implib:"nul" fails miserably when the linker uses it to name the .exp file. The most practical solution is to remove the files again after a build. Project + Properties, Build Events, Post-Build event and paste:

del $(TargetDir)$(TargetName).lib
del $(TargetDir)$(TargetName).exp

enter image description here

Using a .def file containing your exported functions marked with the PRIVATE keyword will tell the linker to skip placing the symbol in your import library.

Refer to this MSDN page for more information about MSVC's .def file syntax.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top