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: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
Hmm... Registering an OID dedicated to express this case should be feasible, and perfectly within the ASN.1 rules. One question - where in the OID tree would it live, as offhand I don't have any idea. It can't be too deep down, and also, it better be fairly short. >From the ASN.1 point of view - there's nothing dumb in this idea. There's >plenty of MIB objects expressing/representing all kinds of things - might as >well add this. On 3/22/19, 12:34, "openssl-users on behalf of Michael Wojcik" wrote: > From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Thursday, March 21, 2019 14:07 > To: openssl-users@openssl.org > > > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni > wrote: > > > >2. Emit a "harmless" default OID (such as 0.0), returning to > > the behaviour prior to 1.0.1i What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer. I'm by no means an ASN.1 expert, so this may be a dumb idea. -- Michael Wojcik Distinguished Engineer, Micro Focus smime.p7s Description: S/MIME cryptographic signature
RE: i2d_X509_REQ() -> d2i_X509_REQ() = asn1 encoding routines:c2i_ASN1_OBJECT:invalid object encoding:a_object.c:287
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of > Viktor Dukhovni > Sent: Thursday, March 21, 2019 14:07 > To: openssl-users@openssl.org > > > On Mar 21, 2019, at 1:57 PM, Viktor Dukhovni > wrote: > > > >2. Emit a "harmless" default OID (such as 0.0), returning to > > the behaviour prior to 1.0.1i What about registering a new OID for "missing required object"? Then at least there'd be a standard way to represent this case, and other parsers could decide to accommodate it however they prefer. I'm by no means an ASN.1 expert, so this may be a dumb idea. -- Michael Wojcik Distinguished Engineer, Micro Focus
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
