I tried to compile OpenSSL using MinGW on Linux, but I could not do
this.
I've tried to modify configurations, converting ms/mingw.bat to
ms/mingw.sh, removing the translation of / into \, and more...
For reference. Occasional mingw tests are performed with Unix build
procedure nowadays. I
In Debian on Linux / i386, we actually build the shared library 4
times with different optimizations. Once for i386, once for i486, 586,
686/cmov.
Does it really help? I can understand i386 for broadest binary
compatibility, but the rest can as well be code generated for i486 but
optimized
On 2006.10.20 at 08:44:14 +0200, Andy Polyakov wrote:
Before I making too much modifications,
Have anyone succeeded in doing so?
I do it routinely.
1. Modify Configure script, adding target
mingw-cross
(this all should go into one line)
mingw-cross, i586-mingw32msvc-gcc:-mno-cygwin
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
Can you test if './Configure mingw' followed by 'make
CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean
It seems to work. Although when I start make test on real win32 system
Oh, it was with our modified
Can you test if './Configure mingw' followed by 'make
CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib' works? I mean
It seems to work. Although when I start make test on real win32 system
Oh, it was with our modified Configure. When I've restarted build with
unmodified 0.9.9 source
On 2006.10.20 at 10:56:35 +0200, Andy Polyakov wrote:
It is not perfect to, because it assumes that if one uses mingw32
target, there is always some Unix emulation environment (i.e. cygwin,
msys or real Unix in case of cross-builds).
As implied earlier I'd actually prefer this, i.e. mingw
On Oct 20 13:33, Victor B. Wagner wrote:
On 2006.10.20 at 10:56:35 +0200, Andy Polyakov wrote:
It is not perfect to, because it assumes that if one uses mingw32
target, there is always some Unix emulation environment (i.e. cygwin,
msys or real Unix in case of cross-builds).
As implied
On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
I'm not an expert on Win32 tcpip history and cannot tell whether it is
problem of my mingw32 runtime headers or something also.
ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
for supporting old Winsock 1.1
On 2006.10.20 at 13:33:37 +0400, Victor B. Wagner wrote:
NM=i586-mingw32msvc-nm
(i've patched Makefile.shared to support NM overriding),
I get following results:
shared library cryptoeay-0.9.8.dll (why not 0.9.9?) is created,
but it exports no symbols. So build of ssleay-0.9.8.dll fails
On Oct 20 14:28, Victor B. Wagner wrote:
On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
for supporting old Winsock 1.1 applications. A modern Winsock 2
application should include winsock2.h and ws2tcpip.h.
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
So, use IPV6 on native windows requires considerable changes anyway?
I wouldn't say it's considerable. Just a tweak to the loading of
getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c, AFAICS.
Implementing of dynamic loading by hand
Now I've managed to cross-compile current CVS tree with
Mingw32 crosscompiler both in static and shared version.
Following changes are needed to the source tree:
1. Configure
1.1. Add -Wl,--export-all to the shared library linker command line
1.2. Add -lws2_32 to list of
So, use IPV6 on native windows requires considerable changes anyway?
I wouldn't say it's considerable. Just a tweak to the loading of
getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c, AFAICS.
And since we have to include ws2tcpip.h anyway for structure
definitions, we should provide way to
On 2006.10.20 at 15:41:35 +0400, Victor B. Wagner wrote:
I was to quick to send previous patch. Two additional changes
are required: changing order of
#include openssl/engine.h
and #include apps.h in apps/apps.c
and order of openssl/rand.h and ../e_os.h in test/randtest.c
Updated patch
On Oct 20 15:21, Victor B. Wagner wrote:
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
So, use IPV6 on native windows requires considerable changes anyway?
I wouldn't say it's considerable. Just a tweak to the loading of
getaddrinfo/freeaddrinfo in crypto/bio/b_sock.c,
On 2006.10.20 at 13:01:01 +0200, Corinna Vinschen wrote:
On Oct 20 14:28, Victor B. Wagner wrote:
On 2006.10.20 at 11:49:39 +0200, Corinna Vinschen wrote:
ws2tcpip.h is incompatible with winsock.h since winsock.h is only meant
for supporting old Winsock 1.1 applications. A modern
On 2006.10.20 at 13:51:47 +0200, Andy Polyakov wrote:
Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
was to target all NT versions [note that 0x333 actually covers even for
Windows 9x, which has at least all 0x333 stubs, so that application can
actually start]. As
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
Haven't you yourself mentioned that one needs to generate .def file as
well? Care
On Oct 20 13:51, Andy Polyakov wrote:
Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
was to target all NT versions [note that 0x333 actually covers even for
Windows 9x, which has at least all 0x333 stubs, so that application can
actually start]. As for winsock
On 2006.10.20 at 14:12:44 +0200, Andy Polyakov wrote:
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
Haven't you yourself mentioned
On 2006.10.20 at 12:05:11 +0400, Victor B. Wagner wrote:
Second problem with cross build is that make does certificate
rehash, using freshly compiled c_rehash program. It doesn't lead to make
failure, but it would be nice to be able to redefine c_rehash as well,
and use one from host system
Keep in mind that mingw defines _WIN32_WINNT=0x333, i.e. the intention
was to target all NT versions [note that 0x333 actually covers even for
Windows 9x, which has at least all 0x333 stubs, so that application can
actually start]. As for winsock versioning. Upon latest modifications to
2. Makefile.shared
Define NM variable to hold name of nm program (which also differs
from just nm when cross-compiling)
Replace explicit call to nm by reference to this variable.
Haven't you yourself mentioned that one needs to generate .def file as
well? Care to
On Oct 20 15:05, Andy Polyakov wrote:
Seriously, I'd consider Winsock 1.1 as the one which should be left
behind, rather than Windows 2000 users.
Windows 2000 users are not left behind, IPv6 on 2000 would be.
That's what I meant :)
Keep in mind 0x333, it's 3.51. If we switch to ws2_32, I'd
Hello Roumen,
On Tuesday, October 17, 2006 at 17:52:34 +0200, Roumen Petrov via RT wrote:
Please could you defail used software.
The simplest failing setup is:
-a) Sending Linux Debian Woody box:
- OpenSSL 0.9.8d (built from tarball)
- Exim 3.35-1woody2
- Qpopper 4.0.4-2.woody.1
Seriously, I'd consider Winsock 1.1 as the one which should be left
behind, rather than Windows 2000 users.
Windows 2000 users are not left behind, IPv6 on 2000 would be.
That's what I meant :)
On bright side one can simply throw in
LoadLibrary(wship6.dll) literally anywhere, e.g. next to
With this patch, instead of the subjectAltName getting
othername:unsupported it will be something like
othername:UPN[EMAIL PROTECTED]
Nice when working with ceritifcates from CAC cards.
__
OpenSSL Project
http://blog.gmane.org/gmane.comp.encryption.openssl.devel/month=20030201
There is an known issue with SSL_CTX_use_certificate_chain_file
where it checks the error stack after calling SSL_CTX_use_certificate,
even if a successful return was reported.
A previous SSL error on the same thread can
It just occurred to me that the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed (type
REG_BINARY) contains the latest seeded value from everything that
CryptoAPI takes into account when generating its random seed.
CryptoAPI permutes it with RC4 to come up with a
On Fri, Oct 20, 2006, Andy Polyakov wrote:
For reference. I was always wondering why do our dlls have to export
things by ordinal and not by name? It would make sense if we maintained
backward binary compatibility [so that incompatible functions with same
name would be exported under
First, sorry for posting to -users and -dev. I'm not sure which is
more appropriate.
I'm working on an embedded system with no operating system and am only
interested in signature verification. I've looked at the config and
have decided to go with no-threads no-zlib no-shared. But I'm
having
31 matches
Mail list logo
