Re: [openssl.org #2382] Win98 mingw problem with openssl head
I used this as a jumping point to investigate and can share some information about the build on Win98 with mingw. I am also attaching a patch for you to look at. Please verify http://cvs.openssl.org/chngview?cn=20153. It turns out that despite the logs I submitted to you, unicows wasn't being used. A strings openssl.exe revealed no unicows string in the executable. When I instead added -lunicows to the beginning of the $lflags variable for mingw's config-string in Configure, unicows.dll began to appear in the executable file. I am not sure why this is. Neither am I... Why would implied change of linking order make such difference? But on the other hand why should it appear at all in either case? It should only appear if there is a reference to a UNICODE function from one of the real object modules. Real is used here to distinguish actual binary code from import stubs commonly found in e.g. libkernel32.a. And there shouldn't be any... In VC-WIN32 build we link with unicows.lib only if we compile with *optional* -DUNICODE, so it shouldn't be required in mingw build either... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2323] bug in openssl commandline tool with md5 fingerprint output
I've meanwhile checked apps/x509.c, and patching it to send output to file is trivial (attached); but looking at the other output options around these lines makes me a bit unsure if these options are intended to go to STDOUT rather than to honor a file option? However if the later then I'm asking me why? Almost all options print their output to STDOUT and ignore a file option - except for the text option ... no comments on this? Is this behaviour now intended? Then lets close the RT with a comment stating this; or just an oversight, and can we then fix this (see my patches)? I'd argue that it's intentional. The original purpose for -out option appears to be to emit *certificate* itself, not information about it. Yes, this kind of means that I reckon that -text option should result in output to STDout, not to one appointed by -out. There also is inconsistent usage of STDout when treating -days parameter: error message should be printed on stderr, not STDout. If nobody screams for a week, http://cvs.openssl.org/chngview?cn=20156 will go down to 1.0.x. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2390] 32 bit compile on Solaris amd64 arch fails in test
I configured the build using: ./Configure solaris-x86-gcc --prefix=/usr/local --openssldir=/usr/local/openssl shared so we can get a 32 bit build on our amd64 Solaris architecture. It core dumps when running the tests. This discussed in PROBLEMS file in source tree, search for Solaris x86. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: buid STABLE-SNAP-20101124 on platform: VMS IA64 V8.3
ALL TESTS SUCCESSFUL. OpenSSL 1.0.1-dev xx XXX built on: 7-DEC-2010 11:34:44.59 platform: VMS IA64 V8.3 Not that I claim to know everything about VMS, but it should be possible to use IA64 assembler modules even on VMS. Not that I'm volunteering to actually do it, but I can provide certain help in case something is not right... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [PATCH] Openssl asm BN/AES/SHA1 acceleration for SH4 and MIPS32
Vincent, Now back to As I don't have access to little-endian MIPS, I'd like to reserve for option to ask you test it at some later point. I've just committed aes-mips.pl module, see http://cvs.openssl.org/chngview?cn=19941, and wonder if you could test it on your system? A lot of thanks in advance. Please?! A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2382] Win98 mingw problem with openssl head
On Sun, 12 Dec 2010, Andy Polyakov via RT wrote: I used this as a jumping point to investigate and can share some information about the build on Win98 with mingw. I am also attaching a patch for you to look at. Please verify http://cvs.openssl.org/chngview?cn=20153. I just compiled on Windows98 for mingw under cygwin, configured with ./Configure no-shared no-idea --prefix=d\:/cygwin/mingw mingw, using the Head tarball from 12/12/2010. There were no errors with make depend, make, make test, and make install. I did not link with unicows. The executable identifies itself as: OpenSSL 1.1.0-dev xx XXX built on: Sun Dec 12 13:28:12 PST 2010 platform: mingw options: bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: d:/cygwin/mingw/ssl It turns out that despite the logs I submitted to you, unicows wasn't being used. A strings openssl.exe revealed no unicows string in the executable. When I instead added -lunicows to the beginning of the $lflags variable for mingw's config-string in Configure, unicows.dll began to appear in the executable file. I am not sure why this is. Neither am I... Why would implied change of linking order make such difference? But on the other hand why should it appear at all in either case? It should only appear if there is a reference to a UNICODE function from one of the real object modules. Real is used here to distinguish actual binary code from import stubs commonly found in e.g. libkernel32.a. And there shouldn't be any... In VC-WIN32 build we link I presume it is there because of MultiByteToWideChar, since with unicows, the function is different, accepting the flag MB_ERR_INVALID_CHARS, which isn't accepted on Win98 without it. with unicows.lib only if we compile with *optional* -DUNICODE, so it shouldn't be required in mingw build either... A. Thanks for getting this working on Win98 again. Doug -- Doug Kaufman Internet: dkauf...@rahul.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2382] Win98 mingw problem with openssl head
On Sun, 12 Dec 2010, Andy Polyakov via RT wrote: I used this as a jumping point to investigate and can share some information about the build on Win98 with mingw. I am also attaching a patch for you to look at. Please verify http://cvs.openssl.org/chngview?cn=20153. I just compiled on Windows98 for mingw under cygwin, configured with ./Configure no-shared no-idea --prefix=d\:/cygwin/mingw mingw, using the Head tarball from 12/12/2010. There were no errors with make depend, make, make test, and make install. I did not link with unicows. The executable identifies itself as: OpenSSL 1.1.0-dev xx XXX built on: Sun Dec 12 13:28:12 PST 2010 platform: mingw options: bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -DOPENSSL_THREADS -D_MT -DDSO_WIN32 -mno-cygwin -DL_ENDIAN -DWIN32_LEAN_AND_MEAN -fomit-frame-pointer -O3 -march=i486 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM OPENSSLDIR: d:/cygwin/mingw/ssl It turns out that despite the logs I submitted to you, unicows wasn't being used. A strings openssl.exe revealed no unicows string in the executable. When I instead added -lunicows to the beginning of the $lflags variable for mingw's config-string in Configure, unicows.dll began to appear in the executable file. I am not sure why this is. Neither am I... Why would implied change of linking order make such difference? But on the other hand why should it appear at all in either case? It should only appear if there is a reference to a UNICODE function from one of the real object modules. Real is used here to distinguish actual binary code from import stubs commonly found in e.g. libkernel32.a. And there shouldn't be any... In VC-WIN32 build we link I presume it is there because of MultiByteToWideChar, since with unicows, the function is different, accepting the flag MB_ERR_INVALID_CHARS, which isn't accepted on Win98 without it. with unicows.lib only if we compile with *optional* -DUNICODE, so it shouldn't be required in mingw build either... A. Thanks for getting this working on Win98 again. Doug -- Doug Kaufman Internet: dkauf...@rahul.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
OpenSSL head compiles on DJGPP
I just wanted to report that the head code compiles on DOS with DJGPP without problems using the tarball from 12/12/2010. I configured with perl ./Configure no-threads no-idea 386 --prefix=/dev/env/DJDIR DJGPP. There were no errors with make depend, make, make test, and make install. The executable identifies itself as: OpenSSL 1.1.0-dev xx XXX built on: Sun Dec 12 19:38:58 PST 2010 platform: DJGPP options: bn(64,32) rc4(4x,int) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -I/dev/env/WATT_ROOT/inc -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O2 -Wall -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: /dev/env/DJDIR/ssl Doug -- Doug Kaufman Internet: dkauf...@rahul.net __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
