Actually, I have an application and a DLL. The DLL depends on the
previous libraries. And I just saw the applink.c tip in the FAQ. As I
don't really want to debug OpenSSL, but rather my application and my
DLL, I have included applink.c in my DLL project, compiled it in Debug
mode (/MDd) against a Release (/MD) libeay32, compiled the executable in
Debug mode and ran it. I get the "no OPENSSL_Applink" error again. Any
help please? Thanks.
You need to do some jiggery-pokery to get the Applink table to appear
properly named in the symbol table.
... in the [export] symbol table of the *application*. The applink.c
module has to be lunked into *application,* not some other dll, even if
it's dll that links with openssl dll and not application itself.
We had to declare it (using Borland) as;
extern "C"
{
__declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
{
...
}
}
extern "C" makes perfect sense, but PASCAL? It doesn't make sense...
Documentation references indicate that PASCAL capitalizes name [not to
mention alternative argument passing convention, but it's lesser problem
in this case, because we don't pass any arguments here], which means
that exported symbol should come out incompatible... So how come it
worked? But Borland apparently supports __cdecl, can you verify if it
does the trick?
The "extern C" stops name mangling happening, the "Pascal" stops an
underscore being prepended to the name.
But Microsoft C prepends the name with underscore... Well, it's then
stripped off by linker... I always get a bit dizzy in between Win32
compilers...
It's not mentioned otherwise because the Uplink system uses
"GetProcAddress" to provide runtime name resolution instead of a
compile-time dependency.
Correct. And the symbol is looked up in .exe image used to create
current process. A.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
