having both release and debug version of openssl on win32?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

having both release and debug version of openssl on win32?

Julien ALLANOS
Hello,

I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,
and other libraries. Thus I have to build them all using the same link
configuration (/MD). However I want to be able to debug my application,
and have both Release and Debug versions of every libraries in the same
time on disk. Is there a way to build libeay32D.{lib|dll},
ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build process?

Thanks,
--
Julien ALLANOS
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Julien ALLANOS
Julien ALLANOS a écrit :

> Hello,
>
> I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,
> and other libraries. Thus I have to build them all using the same link
> configuration (/MD). However I want to be able to debug my application,
> and have both Release and Debug versions of every libraries in the same
> time on disk. Is there a way to build libeay32D.{lib|dll},
> ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build
> process?
>
> Thanks,

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.
--
Julien ALLANOS
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Katie Lucas
On Mon, Nov 07, 2005 at 05:37:59PM +0100, Julien ALLANOS wrote:

> Julien ALLANOS a écrit :
> >Hello,
> >
> >I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,
> >and other libraries. Thus I have to build them all using the same link
> >configuration (/MD). However I want to be able to debug my application,
> >and have both Release and Debug versions of every libraries in the same
> >time on disk. Is there a way to build libeay32D.{lib|dll},
> >ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build
> >process?
> >
> >Thanks,
>
> 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.

We had to declare it (using Borland) as;

extern "C"
{

  __declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
  {
    ...
  }
}

The "extern C" stops name mangling happening, the "Pascal" stops an
underscore being prepended to the name. The "__declspec(dllexport)" is
needed to stop the linker going "hey, this isn't mentioned, I'll
remove it".

It's not mentioned otherwise because the Uplink system uses
"GetProcAddress" to provide runtime name resolution instead of a
compile-time dependency.

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Julien ALLANOS
Katie Lucas a écrit :

> On Mon, Nov 07, 2005 at 05:37:59PM +0100, Julien ALLANOS wrote:
>
>>Julien ALLANOS a écrit :
>>
>>>Hello,
>>>
>>>I have a Win32 application that uses OpenSSL 0.9.8a, libxml2, xmlsec,
>>>and other libraries. Thus I have to build them all using the same link
>>>configuration (/MD). However I want to be able to debug my application,
>>>and have both Release and Debug versions of every libraries in the same
>>>time on disk. Is there a way to build libeay32D.{lib|dll},
>>>ssleay32D.{lib|dll} and opensslD.exe, using the current win32 build
>>>process?
>>>
>>>Thanks,
>>
>>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.
>
> We had to declare it (using Borland) as;
>
> extern "C"
> {
>
>   __declspec(dllexport) void** PASCAL OPENSSL_Applink(void)
>   {
>     ...
>   }
> }
>
> The "extern C" stops name mangling happening, the "Pascal" stops an
> underscore being prepended to the name. The "__declspec(dllexport)" is
> needed to stop the linker going "hey, this isn't mentioned, I'll
> remove it".
>
> It's not mentioned otherwise because the Uplink system uses
> "GetProcAddress" to provide runtime name resolution instead of a
> compile-time dependency.
>

It still doesn't work. And the xmlsec building process doesn't include
applink.c, so I would rather be interested in building a Debug version
of OpenSSL, but changing names of libraries to add a "D" (libeay32D,
ssleay32D...), to be able to have Release and Debug versions side by side.

For the moment, I have:

1/ set "mk1mf.pl debug" into ms\do_masm.bat

2/ run perl Configure VC-WIN32

3/ run ms\do_masm.bat

4/ replaced:

  * SSL=ssleay32 by SSL=ssleay32D
  * SSL=ssleay32 by SSL=ssleay32D

in ms\ntdll.mak

5/ run nmake.exe /f ms\ntdll.mak

I get libeay32D.{lib|dll} and ssleay32D.{lib|dll}, which looks fine, but
actually ssleay32.dll get linked against libeay32.dll, not libeay32D.dll!!

Any hint please? Thanks!
--
Julien ALLANOS
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Julien ALLANOS
Julien ALLANOS a écrit :
> actually ssleay32.dll get linked against libeay32.dll, not libeay32D.dll!!

Of course I meant ssleay32D.dll.
--
Julien ALLANOS
______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Andy Polyakov
In reply to this post by Katie Lucas
>>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                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: having both release and debug version of openssl on win32?

Katie Lucas
On Tue, Nov 08, 2005 at 06:04:05PM +0100, Andy Polyakov wrote:

> 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?

I agree, the docs for BC++ indicate it should affect the name in other
ways, but it did solve the issue of the GetProcAddress not finding the
name.. Sadly I gave up experimenting after this since we couldn't get
the thing to work reliably even given that, and eventually we coerced
a build to happen with BC++6 which works all lovely and nice and
everything "just happens".

> 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...

Ah, I think it's that that's the issue -- the BC++ linker doesn't
(IIRC) strip off the underscore[1]. ISTR something involving adding them while
doing VC++ -> BC++ library conversions. (It's been a while).





[1] I miss UNIX's "nm" SO much while doing this stuff...

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]