How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

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

How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

aaron.friesen

A current project using Net-SNMP and OpenSSL require that these both are built locally (customer requirement).

 

I am attempting to build OpenSSL 1.1.1.

 

After building OpenSSL, “nmake test” succeeds.

 

However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but do not seem to be in what I build locally.

 

From the pre-built package, in the lib/VC folder:

libcrypto64MD.lib

libcrypto64MDd.lib

libcrypto64MT.lib

libcrypto64MTd.lib

libssl64MD.lib

libssl64MDd.lib

libssl64MT.lib

libssl64MTd.lib

 

But the VC folder is not part of my locally built version.

 

What am I missing in order to get these .lib files to build locally?

 

Thank you for your assistance.

 

Best Regards,
Aaron Friesen


Contract Software Engineer of Aerotek on behalf of Keysight

 

Keysight Technologies, Inc.

970.679.5632 T

 


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

Richard Levitte - VMS Whacker-2
Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

    libcrypto-1_1.dll & libssl-1_1.dll           - VC-WIN32 build
    libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
    libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message <[hidden email]> on Mon, 1 Oct 2018 16:29:15 +0000, <[hidden email]> said:

> A current project using Net-SNMP and OpenSSL require that these both are built locally (customer
> requirement).
>
> I am attempting to build OpenSSL 1.1.1.
>
> After building OpenSSL, “nmake test” succeeds.
>
> However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but
> do not seem to be in what I build locally.
>
> From the pre-built package, in the lib/VC folder:
>
> libcrypto64MD.lib
>
> libcrypto64MDd.lib
>
> libcrypto64MT.lib
>
> libcrypto64MTd.lib
>
> libssl64MD.lib
>
> libssl64MDd.lib
>
> libssl64MT.lib
>
> libssl64MTd.lib
>
> But the VC folder is not part of my locally built version.
>
> What am I missing in order to get these .lib files to build locally?
>
> Thank you for your assistance.
>
> Best Regards,
> Aaron Friesen
>
> Contract Software Engineer of Aerotek on behalf of Keysight
>
> Keysight Technologies, Inc.
>
> 970.679.5632 T
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

OpenSSL - User mailing list
Could that be LibreSSL? (Or some similar wrapper for OpenSSL?)


This above repo creates libraries in the named format below; to match how Microsoft provides multiple versions of libraries.

Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not sure what MD stands for.

Also:


--
-Todd Short
// "One if by land, two if by sea, three if by the Internet."

On Oct 2, 2018, at 11:59 AM, Richard Levitte <[hidden email]> wrote:

Our scripts have *never*, as far as I know, produced libraries named
like that.  Don't those DLLs come from some specific packager that
produces binary install kits?

For 1.1.x, *our* naming is a bit more elaborate, you will see these
names:

   libcrypto-1_1.dll & libssl-1_1.dll           - VC-WIN32 build
   libcrypto-1_1-x64.dll & libssl-1_1-x64.dll   - VC-WIN64A build
   libcrypto-1_1-ia64.dll & libssl-1_1-ia64.dll - VC-WIN64I build

You will also see the corresponding import libraries: libcrypto.lib &
libssl.lib

Cheers,
Richard

In message <[hidden email]> on Mon, 1 Oct 2018 16:29:15 +0000, <[hidden email]> said:

A current project using Net-SNMP and OpenSSL require that these both are built locally (customer
requirement).

I am attempting to build OpenSSL 1.1.1.

After building OpenSSL, “nmake test” succeeds.

However, the Net-SNMP build is looking for various .lib files that are in the pre-built package, but
do not seem to be in what I build locally.

From the pre-built package, in the lib/VC folder:

libcrypto64MD.lib

libcrypto64MDd.lib

libcrypto64MT.lib

libcrypto64MTd.lib

libssl64MD.lib

libssl64MDd.lib

libssl64MT.lib

libssl64MTd.lib

But the VC folder is not part of my locally built version.

What am I missing in order to get these .lib files to build locally?

Thank you for your assistance.

Best Regards,
Aaron Friesen

Contract Software Engineer of Aerotek on behalf of Keysight

Keysight Technologies, Inc.

970.679.5632 T

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: How to build libcrypto64*.lib and libssl64*.lib on Windows 64-bit?

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of Short, Todd via openssl-users
> Sent: Monday, October 08, 2018 09:56

> Looks to be debug (d) and multi-thread (MT?) versions of the libraries; not sure what MD stands for.

It's Microsoft's naming convention for their C runtime. MT is multithreaded, statically linked; MD is multithreaded, dynamically linked. The "d" suffix is, as Todd guessed, the debug version.

This is important with Microsoft Visual C, because the various runtimes do not play together. Their heaps, iobs, etc are separate. So, for example, if you link your program with the MT runtime and with a library that was linked with the MD runtime, and your code tries to free memory allocated by the library, you'll get a heap exception (if you're lucky) or heap corruption.

You can get away with mixed runtimes if you're careful - if every module frees the storage it allocates, and you don't try to create a FILE* in one and use it in another, and so on. Nonetheless, it's a gaping architectural flaw, and some packages try to accommodate it by providing equivalent versions of their libraries.

Todd may well be correct that OP is looking at a LibreSSL package, not an OpenSSL one. (LibreSSL isn't "a wrapper for OpenSSL", but whatever.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users