Using (not building) openssl with mingw on Windows 10

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

Using (not building) openssl with mingw on Windows 10

Ken Goldman-2
I've been happily using the Shining Light 32-bit binaries with both
openssl 1.0 and 1.1 and mingw.

On a new machine, I tried the 64-bit binaries.  However, they're missing
the openssl/lib/mingw directory where the .a files resided.

It looks like the link procedure changed.  Any hints before I start
experimenting?

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

Re: Using (not building) openssl with mingw on Windows 10

OpenSSL - User mailing list
On 26/10/2018 23:08, Ken Goldman wrote:
> I've been happily using the Shining Light 32-bit binaries with both
> openssl 1.0 and 1.1 and mingw.
>
> On a new machine, I tried the 64-bit binaries.  However, they're
> missing the openssl/lib/mingw directory where the .a files resided.
>
> It looks like the link procedure changed.  Any hints before I start
> experimenting?
>
Note that Win32 (Microsoft) .LIB files are actually standard unix-style
.a files with the file names changed to match the the historic
MS-DOS/Win16 practice (which had a different file format).

So it is highly likely the .LIB files can be used with mingw by just
copying/symlinking them, or even just using a Mingw option to load
.LIB files.

Beware however of the crazy GNU interpretation that listing a library
file explicitly means include *all* the code from the library, not
just the referenced object files.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

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

Re: Using (not building) openssl with mingw on Windows 10

Ken Goldman-2
On 10/29/2018 7:18 AM, Jakob Bohm via openssl-users wrote:

> On 26/10/2018 23:08, Ken Goldman wrote:
>> I've been happily using the Shining Light 32-bit binaries with both
>> openssl 1.0 and 1.1 and mingw.
>>
>> On a new machine, I tried the 64-bit binaries.  However, they're
>> missing the openssl/lib/mingw directory where the .a files resided.
>>
>> It looks like the link procedure changed.  Any hints before I start
>> experimenting?
>>
> Note that Win32 (Microsoft) .LIB files are actually standard unix-style
> .a files with the file names changed to match the the historic
> MS-DOS/Win16 practice (which had a different file format).
>
> So it is highly likely the .LIB files can be used with mingw by just
> copying/symlinking them, or even just using a Mingw option to load
> .LIB files.
>
> Beware however of the crazy GNU interpretation that listing a library
> file explicitly means include *all* the code from the library, not
> just the referenced object files.

Getting back to this:

I tried mingw linking against these

"c:/program files/openssl64/lib/libcrypto.lib"
"c:/program files/openssl64/lib/libssl.lib"

but the gcc linker failed to find the openssl functions.

Anyone have any ideas?

~~

I observe that the .a file is 3 mb while the .lib is 900k.

~~

The 32-bit build still has the mingw .a files, which I suppose
is a work around.


Reply | Threaded
Open this post in threaded view
|

RE: Using (not building) openssl with mingw on Windows 10

Michael Wojcik
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Ken Goldman
> Sent: Wednesday, March 20, 2019 08:46
> To: [hidden email]
> Subject: Re: Using (not building) openssl with mingw on Windows 10
>
> On 10/29/2018 7:18 AM, Jakob Bohm via openssl-users wrote:
> > Note that Win32 (Microsoft) .LIB files are actually standard unix-style
> > .a files with the file names changed to match the the historic
> > MS-DOS/Win16 practice (which had a different file format).
> >
> > So it is highly likely the .LIB files can be used with mingw by just
> > copying/symlinking them, or even just using a Mingw option to load
> > .LIB files.
> >
> > Beware however of the crazy GNU interpretation that listing a library
> > file explicitly means include *all* the code from the library, not
> > just the referenced object files.
>
> Getting back to this:
>
> I tried mingw linking against these
>
> "c:/program files/openssl64/lib/libcrypto.lib"
> "c:/program files/openssl64/lib/libssl.lib"
>
> but the gcc linker failed to find the openssl functions.
>
> Anyone have any ideas?
>
> ~~
>
> I observe that the .a file is 3 mb while the .lib is 900k.

Sounds like you might have import libraries there. Does "ar t libcrypto.lib" show a bunch of .obj members, or a bunch of .dll members? If it's the latter, then it's just an import library that tells the linker what DLL needs to be loaded at runtime.

We build static (non-import) OpenSSL libraries for Windows, but at least for 1.0.2 we had to tweak the configuration process. The stock Configure wanted to link OpenSSL with the static Microsoft C runtime if you were building static libraries, whereas we wanted static libraries linked with the dynamic runtime. (I don't remember offhand if we had to do the same for 1.1.1.)

--
Michael Wojcik
Distinguished Engineer, Micro Focus


Reply | Threaded
Open this post in threaded view
|

Re: Using (not building) openssl with mingw on Windows 10

Sergio NNX
In reply to this post by Ken Goldman-2
>> I've been happily using the Shining Light 32-bit binaries with both
>> openssl 1.0 and 1.1 and mingw.

a) Where can we download OpenSSL binaries (x64) for Windows built with MinGW?
    [ https://slproweb.com/products/Win32OpenSSL.html ]

b) D:\Temp-Apps\OpenSSL-Win64\bin>openssl version -a

    OpenSSL 1.1.1b  26 Feb 2019
    built on: Wed Feb 27 02:30:51 2019 UTC
    platform: VC-WIN64A
    options:  bn(64,64) rc4(16x,int) des(long) idea(int) blowfish(ptr)
    compiler: cl /Z7 /Fdossl_static.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -D_USING_V110_SDK71_ -D_WINSOCK_DEPRECATED_NO_WARNINGS
    OPENSSLDIR: "C:\Program Files\Common Files\SSL"
    ENGINESDIR: "C:\Program Files\OpenSSL\lib\engines-1_1"
    Seeding source: os-specific

     + Paths seem to be hardcoded

c) D:\Temp-Apps\OpenSSL-Win64\bin>openssl engine capi -v -t -post list_containers
    6840:error:25078067:DSO support routines:win32_load:could not load the shared library:crypto\dso\dso_win32.c:107:filename(C:\Program Files\OpenSSL\lib\engines-1_1\capi.dll)
    6840:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto\dso\dso_lib.c:162:
    6840:error:260B6084:engine routines:dynamic_load:dso not found:crypto\engine\eng_dyn.c:414:
    6840:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto\engine\eng_list.c:334:id=capi

d) Unable to find any .a file within the installation folder (D:\Temp-Apps\OpenSSL-Win64)
    
>> On a new machine, I tried the 64-bit binaries.  However, they're
>> missing the openssl/lib/mingw directory where the .a files resided.

> Getting back to this:

> I tried mingw linking against these

> "c:/program files/openssl64/lib/libcrypto.lib"
> "c:/program files/openssl64/lib/libssl.lib"

> but the gcc linker failed to find the openssl functions.

> Anyone have any ideas?

We have been using OpenSSL for Windows (x64) built with MinGW for a long time.

> openssl.exe version -a

    OpenSSL 1.1.1a  20 Nov 2018
    built on: Sat Feb 23 14:32:38 2019 UTC
    platform: mingw64
    options:  bn(64,64) rc4(16x,int) des(long) idea(int) blowfish(ptr)
    compiler: gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -m64 -O2 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -DUNICODE -D_UNICODE -DWIN32_LEAN_AND_MEAN -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi -DOPENSSL_CAPIENG_DIALOG -m64 -pipe -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -D_MT -DZLIB -DNDEBUG -I/mingw/include
    OPENSSLDIR: "\OpenSSL"
    ENGINESDIR: "\OpenSSL\lib\engines-1_1"
    Seeding source: os-specific

> openssl engine
    (rdrand) Intel RDRAND engine
    (dynamic) Dynamic engine loading support
    (padlock) VIA PadLock (no-RNG, no-ACE)
    (capi) CryptoAPI ENGINE

@Ken: this seems to be a quite old thread, but if you need either the include files or the .a files
      or both, we could email them to you.

Regards.
Reply | Threaded
Open this post in threaded view
|

Re: Using (not building) openssl with mingw on Windows 10

Ken Goldman-2
In reply to this post by Michael Wojcik
On 3/20/2019 12:41 PM, Michael Wojcik wrote:

>
> Sounds like you might have import libraries there. Does "ar t
> libcrypto.lib" show a bunch of .obj members, or a bunch of .dll
> members? If it's the latter, then it's just an import library that
> tells the linker what DLL needs to be loaded at runtime.

ar t libcrypto.lib returns about 4100 lines of:

libcrypto-1_1-x64.dll
libcrypto-1_1-x64.dll
...

So it's an 'import library'.  But I get link errors, with each openssl
function missing.

Any clues?

> We build static (non-import) OpenSSL libraries for Windows, but at
> least for 1.0.2 we had to tweak the configuration process. The stock
> Configure wanted to link OpenSSL with the static Microsoft C runtime
> if you were building static libraries, whereas we wanted static
> libraries linked with the dynamic runtime. (I don't remember offhand
> if we had to do the same for 1.1.1.)

I'm not building OpenSSL.  I use Shining Light, because I don't want to
ship OpenSSL with my code and I certainly don't want to require
my users to build it.

Reply | Threaded
Open this post in threaded view
|

Re: Using (not building) openssl with mingw on Windows 10

Ken Goldman-2
In reply to this post by Sergio NNX
On 3/20/2019 6:44 PM, Sergio NNX wrote:

>>> I've been happily using the Shining Light 32-bit binaries with both
>>> openssl 1.0 and 1.1 and mingw.
>
>> Getting back to this:
>
>> I tried mingw linking against these
>
>> "c:/program files/openssl64/lib/libcrypto.lib"
>> "c:/program files/openssl64/lib/libssl.lib"
>
>> but the gcc linker failed to find the openssl functions.
>
>> Anyone have any ideas?
>
> We have been using OpenSSL for Windows (x64) built with MinGW for a long
> time.

Can you send your linker command.  What from the OpenSSL64/lib
directory do you link to?

Below is your compiler command, but it's my linker that's failing.

>      compiler: gcc.exe -m64 -DWINVER=0x0501 -D_WIN32_WINNT=0x0501
> -D_WIN32_IE=0x0501 -DPTW32_STATIC_LIB -D__CLEANUP_C -m64 -O2 -pipe
> -mms-bitfields -fno-builtin -march=core2 -mtune=core2 -DL_ENDIAN
> -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_IA32_SSE2
> -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m
> -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DRC4_ASM
> -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM
> -DECP_NISTZ256_ASM -DX25519_ASM -DPADLOCK_ASM -DPOLY1305_ASM
> -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 -D_WIN32_IE=0x0501
> -DPTW32_STATIC_LIB -D__CLEANUP_C -DUNICODE -D_UNICODE
> -DWIN32_LEAN_AND_MEAN -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi
> -DOPENSSL_CAPIENG_DIALOG -m64 -pipe -mms-bitfields -fno-builtin
> -march=core2 -mtune=core2 -D_MT -DZLIB -DNDEBUG -I/mingw/include
>
> @Ken: this seems to be a quite old thread, but if you need either the
> include files or the .a files
>        or both, we could email them to you.

I have the include files.

I think I need the .a files or equivalent, but I prefer to use the
Shining Light install.  If I get a private copy from you, I have to
distribute it.

Besides the process and legal issues, it doesn't feel right to
distribute security code that I got via email from an unknown
person with the email name 'sfhacker'.  :-)


Reply | Threaded
Open this post in threaded view
|

RE: Using (not building) openssl with mingw on Windows 10

Michael Wojcik
In reply to this post by Ken Goldman-2
> From: openssl-users [mailto:[hidden email]] On Behalf Of
> Ken Goldman
> Sent: Thursday, March 21, 2019 13:44
> To: [hidden email]
>
> On 3/20/2019 12:41 PM, Michael Wojcik wrote:
>
> >
> > Sounds like you might have import libraries there. Does "ar t
> > libcrypto.lib" show a bunch of .obj members, or a bunch of .dll
> > members? If it's the latter, then it's just an import library that
> > tells the linker what DLL needs to be loaded at runtime.
>
> ar t libcrypto.lib returns about 4100 lines of:
>
> libcrypto-1_1-x64.dll
> libcrypto-1_1-x64.dll
> ...
>
> So it's an 'import library'.  But I get link errors, with each openssl
> function missing.
>
> Any clues?

Without picking at the problem files myself, not really. It's probably something that will be fairly obvious in retrospect but I'm not seeing it from here.

The import libraries (I'm assuming libssl.lib is one as well, on your system) basically tell the linker "for this symbol, insert a runtime load reference to this DLL". The Cygwin nm can display the symbols in an import library; I don't remember if MingW includes nm, or know if it understands import libraries.

So well-formed import versions of libcrypto.lib and libssl.lib should name all the public OpenSSL symbols, and you shouldn't get resolution errors when linking against them. You might well get resolution errors at runtime, if the corresponding DLLs can't be found; but not a link time.

I seem to have discarded some of your older messages. Did you ever send us the actual link command that's being used? Maybe that will throw some light on the problem.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



Reply | Threaded
Open this post in threaded view
|

Re: Using (not building) openssl with mingw on Windows 10

Ken Goldman-2
On 3/22/2019 12:18 PM, Michael Wojcik wrote:
>
> I seem to have discarded some of your older messages. Did you ever
> send us the actual link command that's being used? Maybe that will
> throw some light on the problem.

"c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o
libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o
tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o
tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o
CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o
-Wl,--out-implib,libibmtss.a "c:/program
files/openssl64/lib/libcrypto.lib" "c:/program files/MinGW/lib/libws2_32.a"

tsscrypto.o: In function `TSS_Crypto_Init':
c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:109: undefined reference
to `OPENSSL_init_crypto'
tsscrypto.o: In function `TSS_Hash_GetMd':
c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:133: undefined reference
to `EVP_get_digestbyname'
...
continues for all OpenSSL function names

~~

My guess is that this link snippet is wrong, but I don't know what it
should be.

"c:/program files/openssl64/lib/libcrypto.lib"

~~

For Openssl 32-bit, this worked, but the .a is not in the 64-bit Shining
Light build.

"c:/program files/openssl/lib/mingw/libcrypto-1_1.a"


Reply | Threaded
Open this post in threaded view
|

Re: Using (not building) openssl with mingw on Windows 10

Sergio NNX
> "c:/program files/mingw/bin/gcc.exe" -D_MT -DTPM_WINDOWS -I.  -shared -o
> libibmtss.dll tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o
> tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o
> tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o
> CommandAttributeData.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o
> -Wl,--out-implib,libibmtss.a "c:/program
> files/openssl64/lib/libcrypto.lib" "c:/program files/MinGW/lib/libws2_32.a"

> tsscrypto.o: In function `TSS_Crypto_Init':
> c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:109: undefined reference
> to `OPENSSL_init_crypto'
> tsscrypto.o: In function `TSS_Hash_GetMd':
> c:\Users\KennethGoldman\tpm2\utils/tsscrypto.c:133: undefined reference
> to `EVP_get_digestbyname'
> ...
> continues for all OpenSSL function names


It seems to work fine here:

/mingw/bin/gcc.exe -DTPM_WINDOWS -D_MT -L. -shared -Wl,--no-undefined -Wl,--out-implib,libibmtss.dll.a -o libibmtss-1.1.dll \
                        tssfile.o tsscryptoh.o tsscrypto.o tssprintcmd.o tss.o tssproperties.o tssmarshal.o tssauth.o tssutils.o tsssocket.o tssdev.o tsstransmit.o tssresponsecode.o tssccattributes.o tssprint.o Unmarshal.o CommandAttributeData.o tss12.o tssauth12.o tssmarshal12.o Unmarshal12.o Commands12.o tssccattributes12.o CommandAttributeData12.o tss20.o tssauth20.o Commands.o ntc2lib.o tssntc.o -lcrypto -lz -lcrypt32 -lws2_32


Sorry to pollute this list! You will soon find out why!

Out of curiosity, we downloaded ibmtss1331.tar.gz and tried to build it from source (first time ever).

We have been using MSYS/MinGW for quite some time and we build (from source) and deploy large projects (with many dependencies) on a regular basis.
We tried to do the same with this project (ibmtss).
Then, on a MSYS console window we typed: make -f makefile.mak under 'ibmtss1331\utils' folder.

Find some snippets of 'makefile.mak' file:

    * CC = "c:/program files/mingw/bin/gcc.exe"

   * -I"c:/program files/MinGW/include" \
   * -I"c:/program files/openssl/include" \

    * LNLIBS =  "c:/program files/openssl/lib/mingw/libeay32.a" \
         "c:/program files/openssl/lib/mingw/ssleay32.a" \
         "c:/program files/MinGW/lib/libws2_32.a"

  * imaextend.exe: imaextend.o imalib.o $(LIBTSS)
     $(CC) $(LNFLAGS) -L. -libmtss $< -o $@ applink.o imalib.o $(LNLIBS) $(LIBTSS)
 
 
As you can imagine, there are dozens of compilation errors, such as:

    $ make -f makefile.mak all
    "c:/program files/mingw/bin/gcc.exe" -DTPM_WINDOWS -I. -I"c:/program files/MinGW/include" -I"c:/program files/openssl/include"  -Wall -W -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wformat=2 -Wold-style-definition -ggdb -O0 -c -DTPM_TPM20 tssfile.c
    /bin/sh: c:/program files/mingw/bin/gcc.exe: No such file or directory
    make: *** [tssfile.o] Error 127

    cc1.exe: warning: unrecognized command line option '-Wno-self-assign'

Some runtime errors or 'mistakes', such as:

    $ powerup.exe -v
    TSS_Socket_Open: Opening localhost:2322-mssim
    TSS_Socket_Open: Error on connect to localhost:2322
    TSS_Socket_Open: client connect: error 0 No error
    powerup: failed, rc 000b0008
    TSS_RC_NO_CONNECTION - Failure connecting to lower layer

None of the executables provide some sort of version info and/or dependencies info (e.g. OpenSSL version)

It is impossible to figure out how tests can be run! We tried: make -f makefile.mak check and make -f makefile.mak test and we got:

    make: *** No rule to make target `check'.  Stop.

    make: *** No rule to make target `test'.  Stop.

Trying to build from source a 'cousin' project (ibmtpm1332), taken from the same repository,  we came across things like this (we use MinGW x64):

    #elif TPM_POSIX && !defined _LP64
    #define  RADIX_BITS                     32

    #elif TPM_POSIX &&  defined _LP64
    #define  RADIX_BITS                    64

    #elif TPM_WINDOWS
    #define  RADIX_BITS                     32

    #else
    #error "RADIX_BITS is not set"

    #endif

But then you get:

    In file included from BnValues.h:271:0,
                 from Global.h:83,
                 from Tpm.h:71,
                 from AlgorithmCap.c:67:
    TpmToOsslMath.h:83:4: error: #error "Ossl library is using different radix"
    #  error "Ossl library is using different radix"
       ^~~~~
    make: *** [AlgorithmCap.o] Error 1

On the one hand, we are preparing a comprehensive patch as a contribution to the ibmtss/tpm project(s).
On the other hand, we refuse to believe that IBM is 'fostering' these practices and quality in 2019! We have decided to contact IBM to report and discuss this matter.

To my mind, we can conclude that OpenSSL project has nothing to do with the issue reported here. Sorry again!