Hello,
My name is Marton Anka and I have been an OpenSSL user for quite some time. I am the CTO of 3am Labs, and our commercial products (the LogMeIn line and RemotelyAnywhere) have relied on OpenSSL since their inception.
I'd like to suggest a few changes to the Win32 build process.
Our goal is to:
- Provide a .pdb file for release builds as well as debug ones
- Name debug libraries and dlls differently from the release builds
- Link static libraries to the static C runtime, and DLL builds to the DLL C runtime
The first change is to mkdef.pl. mkdef.pl can be invoked like this:
perl util\mkdef.pl 32 libeay > ms\libeay32.def
We've added an additional parameter that generates a module definition file for debug builds:
perl util\mkdef.pl D 32 libeay > ms\libeay32d.def
The resulting debug module definition file refers to the library as libeay32d (or ssleay32d) instead of libeay32 (or ssleay32).
The other change is to VC-32.pl. It does not modify how the script is invoked, but changes the following:
- Release static builds are called ssleay32st.lib and libeay32st.lib
- Release DLL builds are called ssleay32.lib and libeay32.lib
- Debug static builds are called ssleay32std.lib and libeay32std.lib
- Debug DLL builds are called ssleay32d.lib and libeay32d.lib
- Static builds are linked to the static C runtime, release builds are linked to the DLL C runtime
- Debug symbols (pdb files) are generated for both debug and release builds, and the pdb files are named according to the naming convention described in steps 1-4
Finally we've modified /ms/do_masm.bat and /ms/do_ms.bat so they call mkdef.pl for every possible variation:
perl util\mkdef.pl 32 libeay > ms\libeay32.def
perl util\mkdef.pl D 32 libeay > ms\libeay32d.def
perl util\mkdef.pl 32 ssleay > ms\ssleay32.def
perl util\mkdef.pl D 32 ssleay > ms\ssleay32d.def
Please let me know if this could be rolled into the main codeline. I can post diffs (I presume unified format would work) or the whole files themselves.
We have been applying these changes to every release of OpenSSL since the 0.9.6 days, and find them immensely useful.
-Marton Anka
