I thought it was easy from the past experiences. I am not sure if these were bugs in the linker or what, but I had some weird problems trying to get a bit more complex code to compile into a DLL file.
Problem 1: Undefined (*UND*). SymbolI got these very weird errors, stating some symbols I declared being dllexport were undefined. If I didn't have __declspec(dllexport) then those symbols were found fine by the other internal functions, but I wanted them to be usable from external applications loading the library.
The cause seemed to be that for some reason you cannot have a reference to the function before it appears in the source code, e.g.
Code:
void somefunction(int x) {
myexport(x);
}
__declspec(dllexport) __stdcall void myexport(int x) {
printf("%d\n",x);
}
That would say that myexport is undefined. OK, in that example it is as easy as to move the function to be before it is first called, but my situation was more complex; I had two externalized functions that called each other, so no matter in which order I had them in the source code, it would always complain on either of them being undefined.
As the code is supposed to be platform-independent (it compiled and linked just fine under Linux and Solaris already, just Windows was problematic) I made some dirty preprocessor hacks to work around this annoying error.
Since this error only occurred when the functions were __declspec(dllexport), I made one of the problematic exports a normal internal function with different name and made a wrapper with the original name.
This also included that I renamed the function call to be to the internal function everywhere inside the library to prevent extra function calls.
In the private header file (one used when compiling the library itself, not the one to be given to programs using the library):
Code:
#ifndef _WIN32
#define myexport_internal(o) myexport(o)
#endif
Now in the main program the actual function is named myexport_internal and the wrapper is created conditionally:
Code:
#ifndef...