I made a dll from my project and export a function using extern "C" like the code below:
main.cpp
extern "C" __declspec(dllexport) void __cdecl VectorOfMarker(char* InAdd,vector<NewMarker>& VectorMarkers)
{
DetectSeg d;
d.VectorOfMarker(InAdd,VectorMarkers);
}
I build the project and create the .dll and .lib files successfully.
then I create a new visual c++ project and try to use this dll and mentioned function in it.
Although I copied the .dll and .lib files to the same directory but I can't use extern "C" to import my function to the 2nd project. I think that I need to change some settings in visual studio 2010 to use the functions
Can anyone help me for this?
How can I use my exported function?
Too many thanks in advance
I think you are confused as to what type of the dll you are building.
There are two typed of the dynamitic linking implicit and explicit
.
To dynamically link a dll implicitly, you create dll that exports some functions and/or variables. This will create a DLL module and .lib import library. The module that is using this type of the dll, must have header file with function prototypes and must be linked with .lib import library.
So you are linking at the compile time. Since exports are done using __declspec(dllexport) and __declspec(dlleimport) and exported functions names are decorated (mangled). They look like ?ExportedTest##YAXPAD#Z.
Another type is explicit linking and that is most likely what you are doing.
Usually for this type of DLL function are exported using .def files to produce function names that are not decorated. This also can be achieved by using extern "C" modifier to tell C++ compiler to compile function as C style, hence exported function is not decorated and usre _ (underscore).
To use this type of the DLL you have todeclare function type and parameters, call Load library, and GetProcAddress to get function pointer. Then you will be able to make a call as follows:
typedef void (*DLLVectorOfMarker)(char*, vector<int>&);
HMODULE hMod = LoadLibrary(_T("ExportTest.dll")); // your lib name goes here
DLLVectorOfMarker pfnVectorOfMarker = (DLLVectorOfMarker)GetProcAddress(hMod, "VectorOfMarker");
vector <int> VectorMarkers;
pfnVectorOfMarker("some string", VectorMarkers);
Related
I have defined a DLL-export as follows:
__declspec(dllexport)
DWORD WINAPI DllBootstrap(LPVOID addr) {
return 0;
}
Now, using DUMPBIN, the symbol is displayed as follows:
1 0 0001100A ?DllBootstrap##YGKPAX#Z = #ILT+5(?DllBootstrap##YGKPAX#Z)
And this is how the memory looks in Visual Studio:
ยก}....ReflectDLL.dll.?DllBootstrap##YGKPAX#Z..........................................
when inspecting PIMAGE_EXPORT_DIRECTORY.AddressOfNames.
What I need is a clean symbol, i.e., DUMPBIN should output something like:
1 0 0001100A DllBootstrap
and PIMAGE_EXPORT_DIRECTORY.AddressOfNames should point to:
DllBootstrap..........................................
How can I achieve this?
WIN32 BUILDS:
As #RbMm indicated, to retain your function name as-is and get no name decoration, you must use a .DEF file (and remove the __declspec(dllexport) specifier). Then create a DEF file with the line below and either specify it with the /DEF linker option or add it to your Visual Studio project and it will be picked up automatically by the linker:
EXPORTS DllBootstrap
If you don't want to deal with an external .DEF file and you will be using the Visual C++ compiler, the simplest way to limit decoration using just code is to declare your function with 'extern "C"'. This results in decoration including a preceding underscore and appends an "#" along with the argument's byte count in decimal. The following code for example:
extern "C" __declspec(dllexport)
DWORD WINAPI DllBootstrap(LPVOID addr) {
return 0;
}
produces an exported name of:
_DllBootstrap#4
This is how stdcall functions are decorated when C++ name-mangling is disabled with 'extern "C"'. NOTE: WINAPI maps to __stdcall. Retaining 'extern "C"' and changing the convention to __cdecl, you won't get any decoration whatsoever, but module entrypoints should generally remain stdcall as you have it listed in your sample.
If you still want to avoid a .DEF file, there is one last hack you can employ. Add the following line to your code:
#pragma comment(linker,"/EXPORT:DllBootstrap=_DllBootstrap#4")
This will pass an argument to the linker creating a new undecorated name symbol which maps to the decorated name. This isn't very clean as the original name will still exist in your DLL, but you will get your clean exported name.
WIN64 BUILDS (UPDATE):
As Hans Passant commented, for anyone using the Visual C++ 64-bit compiler, there is only the 64-bit calling convention (stdcall, cdecl, etc. keywords are ignored). While C++ mangling will still occur under this compiler, no additional decoration is made to the exported names. In this case, 'extern "C"' would be enough when the sample is compiled as C++ code; if compiled as C, no modifications would be necessary.
I have been using cgo to interface between Go and C. However, when trying to do the same for Go and C++, I get a compile error every time I attempt to call a function. Using go build . from the code's directory, I get the following errors:
./main.go: In function 'void _cgo_3612c872201c_Cfunc_getint(void*)':
./main.go:48:53: error: invalid conversion from 'void*' to '_cgo_3612c872201c_Cfunc_getint(void*)::<anonymous struct>*' [-fpermissive]
./main.go:54:4: error: invalid conversion from 'void*' to '_cgo_3612c872201c_Cfunc_getint(void*)::<anonymous struct>*' [-fpermissive]
I've put a super simple example below which shows the problem.
main.go:
package main
/*
#cgo CFLAGS: -x c++
int getint()
{
return 1;
}
*/
import "C"
import (
"fmt"
)
func main() {
fmt.Println(C.getint())
}
Does anyone know if this is a bug in cgo, or something wrong with how I wrote the code? According to the cgo documentation, C++ is supported. I'm using Go version 1.7.5 for linux/amd64.
Thanks so much!
I may be wrong, but I think cgo supports C++ only in the sense it knows how to invoke a C++ compiler on the non-Go files which looks like containing C++ source code, and that's all.
The problem is that C++ compilers use so-called "mangling" for the symbols made exported from the compiled files. Exporting symbols were originally
intended only for C-like languages, where all which can be exported are plain
functions and variables, but C++ adds classes and function overloading,
and to export such symbols from compiled ("object") files, a C++ compiler
needs to "mangle" them using certain schema to encode names of classes
and types of arguments in these names. What's worse, each C++ compiler
brand uses its own mangling schemas.
So I think while cgo is able to compile C++ code, it sort of assumes that
all the symbols exported (to be used by Go) in your C++ files are
wrapped in extern "C" { ... } (see this).
If you need calls to "native" C++ exported stuff, you'd need to use
SWIG I reckon.
I want to use my school custom library in a C++ project but the library linking seems not working... When I create my program in C and I try to compile it, it work...
See by yourself:
I think that the X11 and/or Xext libraries dependencies of the Mlx are in cause, there can be some
#if __cplusplus
void *x11_mlx_function_wanted(void);
#endif
I had already check if the mlx contains some check like that and I saw nothing.
Thank you in advance
EDIT
And I succeed in objective-c.
The problem is C++ name-mangling. If you declare a function in C11, it ends up with a "mangled" name, which encodes the namespace and the types of the arguments. That's necessary because in C++, various overloads can exist for the same function name. The overloads are independent functions; they do not even have to be in the same object library.
In the object library itself, the functions will have ordinary C names. But since the header file is processed with a C++ compiler, the declared functions will be named as though they were C++ functions.
One possible solution might be to declare all the included functions to be C functions:
extern "C" {
#include "/usr/X11/include/mlx.h"
}
I have written an DLL in Delphi which exports functions. I would like to use these functions in a C++ program without using dynamic Linking (LoadLibrary() API-Call).
The "import" declaration would be
extern "C" int __stdcall getVersionNumber();
I mainly use Bloodshed Dev-C++ which creates Windows Executables. But I do not know how to tell the compiler that it should import the function "getVersionNumber" from "STATMONDLL32.dll".
After I spent many hours by googling the problem, without any result (there was only weird stuff written about .a files and .lib files, which I do not have compiled by Delphi...) I have also installed VC++, but even there, I could not find a way to tell the compiler to use a specific DLL.
I have created a DEF file for this DLL - how can I tell Dev-C++ and/or VC++ to use it? (Dev-C++ prefered)
// Edit: Delphi is creating UNDECORATED symbols. The symbol is exactly "getVersionNumber".
I have created following DEF file with an alias for decoration:
LIBRARY STATMONDLL32
EXPORTS
getVersionNumberA = _getVersionNumberA#0
I have created a *.lib file with VC++ "lib.exe":
lib.exe /DEF:StatMonDll32.def /OUT:StatMonDll32.lib
I have included the lib in VC++ linker settings.
But VC++ tells me that it cannot resolve the external symbol _getVersionNumberA#0 ! Please help!
// Edit: I have uploaded the DLL here: http://www.viathinksoft.de/temp/StatMonDll32.dll . Can you access the symbol getVersionNumberA with VC++ ? I am searching for a solution since 6 days now :'-(
Best regards
Daniel Marschall
You can use dynamic linking, it should work something along the lines of:
extern "C" typedef int (__stdcall *pfnadd)(int a, int b);
extern "C" typedef int (__stdcall *pfngetversion)(void);
HMODULE mod = LoadLibraryA("mydll.dll");
pfnadd add = (pfnadd)GetProcAddress(mod, "Add");
pfngetversion getVersionNumberA =
(pfngetversion)GetProcAddress(mod, "getVersionNumberA");
and then you can just call using the function pointer:
add(1, 2);
std::cout << getVersionNumberA();
Although, it seems like your question has bits and pieces of two different functions!
Visual Studio C++ 2005
Windows XP
I am creating this DLL library. The DLL actually links with another LIB. I have included the headers and lib path. Everything compiles ok.
Actually, this code I wrote for running on linux, which runs ok. Now I am porting it to run on windows.
However, I have noticed that some DLL from some code samples use this in there header file:
static __declspec(dllexport) float some_function(int num1, int num2);
However, I have done the following, sample code below for the header *.h file. However, not sure if I still need the above or not?
#ifdef __cplusplus
extern "C" {
#endif
media_t* get_media(media_description_t* obj);
void* get_item(media_description_list_t *obj, int num);
int get_number_format(media_t *obj);
const char* get_media_value(media_t *obj);
#ifdef __cplusplus
}
#endif
Sample code for for implementation *.cpp file
int get_number_format(media_t *obj)
{
Media *med = (Media*)obj;
return med->getNumFormat();
}
So, do I need this static __declspec(dllexport)?
Many thanks for any advice,
The linker needs to be told which of your functions should be exported, making them usable by other code that uses your DLL. __declspec(dllexport) does this. But you can also do it by providing the linker with a .def file, a list of exported function names. Somewhat painful because it now is up to you to keep that file in sync with your code. Docs are here.
__declspec(dllexport) adds the function to the DLL's export table. This table is a convention that allows a process wishing to use the DLL to correctly call the function.
There are other ways to export functions from DLLs, but this one is probably the more modern and easier to use.
yes it is needed, if you don't have the dllexport the function will not be accessible in any other application where you are calling that function.
If you put the implementation of a method in the h file, you don't need to use the __declspec(dllexport) declaration.