I am trying to build a Dynamic DLL in VC++ 2008, now in a .h file, I declare the following
#ifndef PREFILTER_LIBRARY_H
#define PREFILTER_LIBRARY_H
#ifdef PREFILTER_EXPORTS
# define PREFILTER_API __declspec(dllexport)
#else
# define PREFILTER_API __declspec(dllimport)
#endif
#endif
While in the PreFilter.h file I am writing
class PREFILTER_API PreFilter
{
...
};
The problem is I keep getting:
warning C4273: 'PreFilter::Apply' : inconsistent dll linkage
I see that the dllexport part of the above macros is not highlighted and is commented which should have been the other way around, plus I have another .h file that contains Apply() method.
Can't figure out what I am doing wrong here. I am trying to export the functions of PreFilter.h
Add PREFILTER_EXPORTS to the list of preprocessor constants in Dll project settings: Project - Properties - Configuration Properties - C++ - Preprocessor - Preprocessor definitions.
When this file is used in Dll project, PREFILTER_EXPORTS is defined in the project, and PREFILTER_API is expanded as __declspec(dllexport). In any other project, where PREFILTER_EXPORTS is not defined, PREFILTER_API is expanded as __declspec(dllimport).
Related
I am trying to use a C++Builder 11.1.5 created DLL in MSVC 2022 C++ project. Both are 32bit. I can't build the DLL in MSVC as it uses some VCL objects.
My C++ Builder defines the external function thus:
extern "C" __declspec(dllexport) void __stdcall SetEnabled(bool val) {
...
}
MSVC uses a header to reference the function:
extern "C" __declspec(dllimport) void __stdcall SetEnabled(bool val) ;
I have created a .DEF file with the same name as the DLL, containing this:
LIBRARY MYTESTDLL
EXPORTS
SetEnabled
And I have generated a .LIB file from this .DEF file using MS lib.exe:
lib.exe /DEF:MYTESTDLL.def /out:MYTESTDLL.lib /MACHINE:x86
Finally, I have added MYTESTDLL.lib to my MSVC project in the Linker->Additional Dependencies section.
But, when I build the program, I get this error:
Error LNK2019 unresolved external symbol __imp__SetEnabled#4 referenced in function _WinMain#16
I've tried adding the ordinal (#4) to my .DEF file and rebuilding the .LIB file, but I still get the same error.
In a hex editor, I can that __imp__SetEnabled is in the .LIB file, but clearly not in a way that MSVC likes.
Have I missed a step somewhere? Is there anything obviously wrong with what I've done?
Changing the MSVC header used to reference the function to:
extern "C" __declspec(dllimport) void SetEnabled(bool val) ;
and adjusting the C++Builder DLL to export the functions using __cdecl resolved the issue. I didn't realize that the __stdcall exported functions need decorating in .DEF file.
That said, I find that the DLL is fine unless I try to execute code in it that uses the VCL. Then things don't work properly. I wonder if it's not possible to write a DLL in C++Builder containing VCL code for use in MSVC?
Ultimately I want to end up with a single set of source files that compiles to a Windows or Linux dynamic library depending on which platform compiled it.
The problem seems to be that Windows requires that annotations be made to both the header file declarations and the source file definitions. DLL Tutorial For Beginners
Linux dynamic link libraries seem to require annotations only in the source file definitions.
I can #define a preprocessor string to handle the difference of the source code definitions.
#if (_MSC_VER >= 1900) // (Visual Studio 2015 version 14.0)
#define EXPORTED __declspec(dllexport)
#else
#define EXPORTED __attribute__((visibility("default")))
#endif
Both Windows and Linux ignore empty #define statements.
You may not use annotations in Windows. You can use DEF file for declare export functions .def files C/C++ DLLs
For linux you need to use annotations, e.g.:
int
#ifdef __GNUC__
__attribute__((visibility("default")))
#endif
myfunction(int param) {
return 0;
}
This solves the problem that Windows requires functions
in the DLL header and the DLL source file be annotated
and Linux requires only the LIB source functions to be
annotated. Both Windows and Linux ignore empty #define
statements.
//
// Dynamic Link Library for Linux and Windows
//
// If not >= Visual Studio 2015 (version 14.0) then
// Linux is assumed
//
// This file is inlcluded in all of the LIB/DLL Source
// and the LIB/DLL caller.
//
#if (_MSC_VER >= 1900) // (Visual Studio 2015 version 14.0)
// Windows Function Definition (LIB/DLL Source)
#define EXPORTED_DEF __declspec(dllexport)
// DLL_EXPORT is defined at top of LIB/DLL Source of exported functions
#if defined DLL_EXPORT
// Windows Function Declaration (DLL Header)
#define EXPORTED_DEC __declspec(dllexport) // DLL Export
#else
// Windows Function Declaration (Caller Header)
#define EXPORTED_DEC __declspec(dllimport) // DLL Import
#endif
#else
// Linux Function definition (LIB/DLL Source)
#define EXPORTED_DEF __attribute__((visibility("default")))
#define EXPORTED_DEC // Linux cannot see this
#endif
Assuming I have these two files:
Header.h
class DLL ExportClass{
public:
ExportClass();
static int test;
};
Source.cpp
#ifdef EXPORT
#define DLL __declspec(dllexport)
#else
#define DLL __declspec(dllimport)
#endif
#include "Header.h"
int ExportClass::test = 0;
ExportClass::ExportClass(){
}
And I won't define EXPORT (to import a already exported class with a static member), why do I get these warnings:
1>source.cpp(11): warning C4273: 'test' : inconsistent dll linkage
1> header.h(4) : see previous definition of 'public: static int ExportClass::test'
1>source.cpp(13): warning C4273: 'ExportClass::ExportClass' : inconsistent dll linkage
1> header.h(3) : see previous definition of '{ctor}'
And this error:
1>source.cpp(11): error C2491: 'ExportClass::test' : definition of dllimport static data member not allowed
If I define EXPORT it works. I kind of understand the warnings, but I thought, that the static variable and the ctor could be ignored by the compiler, because the whole class is declared as __declspec(dllimport) anyway. I want to use the same codebase for the __declspec(dllexport) and __declspec(dllimport) - but it seems the compiler stll tries to define these symbols that are marked as __declspec(dllexport) in their declaration. What is the common practice to solve this problem?
You are expecting the compiler to ignore a very serious mishap. It encountered the __declspec(dllimport) attribute on the class declaration, that quite unequivocally states that the class implementation is present in different module that's going to bound at runtime. But then it encountered the definition as well, completely unexpected since the attribute contract says that it is compiled in an entirely different project.
The C4273 warning is generated to remind you that it is very unclear what function is actually going to execute at runtime. There are two, one that is busy compiling, another in the DLL. Which one will actually execute is a wild guess. C4273 is a level 1 warning, the kind that fit the "this is almost surely wrong" category. It is not entirely impossible to work okay since there's some expectation that the functions have at least the same code. The odds that will not cause trouble are however not great, it could only work if the function doesn't have any side effects that change the internal DLL state. Very hard to diagnose bug when it does btw.
Then it encountered the exported variable. Same case, there are two of them. This is where the compiler programmer put his foot down, having code randomly use one or the other is no longer something that can be ignored. That just cannot ever work, the variables cannot have the same value. So C2491 is a hard error.
No idea how you got in this pickle, clearly the road you're trying to travel will make you fall off a steep cliff.
The only way I can reproduce your problem is to do the following:
Create a Win32 DLL project, call it Project1
Add the source code as you described
Compile the DLL and LIB
Change the project properties to remove EXPORT from the preprocessor definitions
Attempt to compile again (then I see your errors/warnings)
If, instead of steps 4 and 5, I do the following, I do not see an error:
Create a Win32 console application, call it Project2
Add source code as follows:
#include "Project1.h"
#pragma comment(lib, "Project1.lib")
int _tmain(int argc, _TCHAR* argv[])
{
ExportClass pClass;
return 0;
}
I suspect you see those errors because you are doing everything from the same DLL project and it is overwriting the LIB that it previously created and then attempting to import it.
If I am correct in guessing what you did, can you try using your DLL/LIB from another project and see what happens?
Although it is an old thread, it will be probably read by others. Therefore, if you want to make this code cross-compilable, I would usually define a header "export.h" like:
export.h
#pragram once
#if ! defined(DLL_API)
# if defined(_WIN32) // for windows builds
# if defined(myDLL_EXPORTS)
# define DLL_API __declspec(dllexport)
# else
# define DLL_API __declspec(dllimport)
# endif
# else // for linux builds
# define DLL_API
# endif
#endif
and include it in all the classes (.h) you want to export from your dll. You will also have to define the variable myDLL_EXPORTS as a parameter of the compiler for the dll project.
The way it works is very simple, when you are compiling your dynamic library (dll/so), because the variable myDLL_EXPORTS is defined, the compiler will replace DLL_API with __declspec(dllexport) so that your class can be consumed by the user of your dll. Conversely, when you are including the header file where you want to use your class at, because the variable myDLL_EXPORTS is not defined in the consumer project (it is defined only in the DLL project), the compiler will replace myDLL_EXPORT with __declspec(dllimport), so it knows that your class symbols are defined somewhere else (in this case, defined in your dll/so).
Finally, as __declspec(...) is a Windows-only thing, for linux we replace DLL_API with nothing.
I have a small issue when it comes to writing a DLL in MSVC (the 2010 version in particular).
My program consists of the main part and a DLL. The DLL contains a function that is
__declspec(dllexport) int test_function(void) {
return 42;
}
The file is compiled using a DLL project (not using pre-compiled headers, I have chosen a empty DLL project). Now, when I want to list the exported symbols using the dumpbin tool, the test_function is not listed under exports. Is there a specific setting that forces __declspec(dllexport) to actually export symbols?
Any help is welcome. Thank you!
That should do it. If this is the whole code, check the following:
1) You are actually checking the correct dll. Look at the timestamp. Double-check the location and the name.
2) You are compiling the specified cpp (I take it your definition is in the cpp file). Just because the file is in the directory doesn't mean it gets compiled, make sure it is added to the project.
3) Make sure your function is not excluded from the compilation unit by preprocessor directives.
Also look for other symbols and try to see what differences are there between the symbols that get exported and your function.
If this fails, you should move __declspec(dllexport) to your .h file and the definition (without __declspec(dllexport) ) to your .cpp. It might not be exported because the compiler might try to optimize it out by inlining it.
I have two existing executables A and T, in the same solution that both ran just fine before I touched them. In executable A is a header defining a class P, and a prototype for a static instance MyP. The definitions are compiled in project A. In executable T, I wanted to call member functions of MyP in project A, so I added dllimport/export macros to the declarations of the class and MyP in the headers (not at the definitions), and included the headers in project T. The dllimport/export macros are standard, and A_EXPORTS is defined in project A, but not in T.
#ifdef A_EXPORTS
#define A_API __declspec(dllexport)
#else
#define A_API __declspec(dllimport)
#endif
//various definitions and includes, defining ENUM_RECORDING_TYPE and ERROR
A_API HFILE viosopen(const _TCHAR *path, ENUM_RECORDING_TYPE rt, int flags);
A_API struct P {
ERROR B(SHORT phraseNum);
};
A_API extern P MyP;
I added project A as a dependency on project T in the solution. A still compiles fine, but T comes up with unresolved external symbol "__declspec(import) <snip> referenced in function <snip> for the function calls, and unresolved external symbol "__declspec(dllimport) class P MyP" <snip> for the static object. I also see in the output log, right after it starts linking: Creating library Debug/A.lib and object Debug/A.exp which seems ominous since it's supposed to be linking against the existing executable.
My question is: how can I tell MSVC 2010 where those are? I thought simply setting A as a dependency would have it figure that out automatically. I can link against the existing executable, right?
To statically link your program you don't need the __declspec() stuff and you don't need a separate project to create a LIB file. I think you can just link using the .obj file from your A project.
Your A project has a header file and presumably has a .cpp file that contains the implementation of the items described in that header. Let's say your header file is foo.h and the associated implementation is foo.cpp. When compiled, there should be a foo.obj intermediate file in the <solutiondir>\A\Debug or <solutiondir>\A\release intermediate folder. That file can be used by the linker.
In project T's properties, find Linker | Input and change the "Additional Dependencies" property to include the foo.obj file. One approach would be to use a relative file path to locate the file - for example ..\A\Debug\foo.obj in your debug configuration. Another approach is to use the simple file name in "Additional Dependencies" - foo.obj - and then use Linker | General | Additional Library Directories" to help the linker find the file - e.g., ..\A\$(IntDir). Using the $(IntDir) macro has the advantage that the same value works for Debug and Release settings.
Remember to set up a build dependency from your T project to your A project to be sure the A project is compiled first. Otherwise the foo.obj file might not exist when the T linker comes to look for it. In the Solution properties, select Project Dependencies and then set Project T depends on Project A.
To dynamically link you need to use the A.LIB file as #ajay said. The __declspec(DllImport) tells the compiler what functions and data you are importing but doesn't tell it where you are importing those things from.
Using the A.LIB file as input to the linker is much the same as using the foo.obj file in the statically linking case except that the lib file ends up in the solution output directory <solutiondir>\Debug instead of the project intermediate directory <solutiondir>\A\Debug.
This walkthrough on creating and using a DLL might be useful background.
I asssume project A is DLL not an EXE, which is successfully producing a LIB file.
You need to use the A.LIB as Linker Input in project B. Just producing LIB file wont make other projects automatically link to it.