RE: Using (not building) openssl with mingw on Windows 10
> From: Michael Wojcik > 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. Here's a new attempt. I added -lcrypto. I also added -L and the path to libcrypto.lib. The error makes sense because -lcrypto should search for libcrypto.a, and there is none in the Shining Light build. I also tried pointing directly to "c:/program files/openssl64/lib/libcrypto.lib", but the link failed. ~~ "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 -L"c:/program files/openssl64/lib" -lcrypto "c:/program files/MinGW/lib/libws2_32.a" c:/program files/mingw/bin/../lib/gcc/mingw32/6.3.0/../../../../mingw32/bin/ld.exe: cannot find -lcrypto
Re: Using (not building) openssl with mingw on Windows 10
> "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_BITS64 #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!
Re: Using (not building) openssl with mingw on Windows 10
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"
RE: Using (not building) openssl with mingw on Windows 10
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Ken Goldman > Sent: Thursday, March 21, 2019 13:44 > To: openssl-users@openssl.org > > 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
Re: Using (not building) openssl with mingw on Windows 10
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'. :-)
Re: Using (not building) openssl with mingw on Windows 10
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.
Re: Using (not building) openssl with mingw on Windows 10
>> 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.
RE: Using (not building) openssl with mingw on Windows 10
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Ken Goldman > Sent: Wednesday, March 20, 2019 08:46 > To: openssl-users@openssl.org > 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
Re: Using (not building) openssl with mingw on Windows 10
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.
Re: [openssl-users] Using (not building) openssl with mingw on Windows 10
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
[openssl-users] Using (not building) openssl with mingw on Windows 10
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
