Closing as well according to #1552
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager
Can be closed in favor of:
http://rt.openssl.org/index.html?q=1552
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List
Any reason why not merge the patch into snapshots?
The only reason is lack of time. Trouble is that there also are other
minor open issues in mingw build and idea is to sit down some day and
reflect over the whole build procedure. A.
On 10/27/07, Andy Polyakov via RT [EMAIL PROTECTED] wrote:
Any reason why not merge the patch into snapshots?
The only reason is lack of time. Trouble is that there also are other
minor open issues in mingw build and idea is to sit down some day and
reflect over the whole build procedure. A.
On 10/27/07, Andy Polyakov via RT [EMAIL PROTECTED] wrote:
Any reason why not merge the patch into snapshots?
The only reason is lack of time. Trouble is that there also are other
minor open issues in mingw build and idea is to sit down some day and
reflect over the whole build procedure. A.
Hello OpenSSL developers,
Any reason why not merge the patch into snapshots?
http://rt.openssl.org/Ticket/Display.html?id=1451
It is important for people who wish to compile to Microsoft platform
without using any Microsoft resources.
Best Regards,
Alon Bar-Lev
Alon Bar-Lev wrote:
Hello,
An update.
1. The issue with OPENSSL_IMPLEMENT_GLOBAL is gone now.
2. Merged with Roumen Petrov's patch:
http://rt.openssl.org/Ticket/Display.html?id=1552
Except of not postfix engine dlls with eay32.
it's working!
thanks!
it'd have to include in the upstream
Alon Bar-Lev wrote:
Hello,
An update.
1. The issue with OPENSSL_IMPLEMENT_GLOBAL is gone now.
2. Merged with Roumen Petrov's patch:
http://rt.openssl.org/Ticket/Display.html?id=1552
Except of not postfix engine dlls with eay32.
it's working!
thanks!
it'd have to include in the upstream
hi,
is there any change to get into the upstream openssl?
it'd be very useful and important to be able to generate win32 binary on
linux.
thnaks in advance.
Alon Bar-Lev wrote:
Hello,
An update.
1. The issue with OPENSSL_IMPLEMENT_GLOBAL is gone now.
2. Merged with Roumen Petrov's patch:
Hello,
An update.
1. The issue with OPENSSL_IMPLEMENT_GLOBAL is gone now.
2. Merged with Roumen Petrov's patch:
http://rt.openssl.org/Ticket/Display.html?id=1552
Except of not postfix engine dlls with eay32.
Best Regards,
Alon Bar-Lev.
---
diff -urNp openssl-SNAP-20070901/Configure
On Saturday 01 September 2007, Alon Bar-Lev via RT wrote:
Hello,
An update.
1. The issue with OPENSSL_IMPLEMENT_GLOBAL is gone now.
2. Merged with Roumen Petrov's patch:
http://rt.openssl.org/Ticket/Display.html?id=1552
Except of not postfix engine dlls with eay32.
Best Regards,
[ping]
Passed a long time since I sent this patch.
MinGW cross compile does not work without it.
Is there something wrong with this patch?
http://rt.openssl.org/Ticket/Display.html?id=1451
Thanks!
Alon Bar-Lev.
__
OpenSSL
Hello,
I don't exactly undersand the maintenance model of OpenSSL.
I would really like to see a milestone set for this issue
(http://rt.openssl.org/Ticket/Display.html?id=1451).
We are waiting for this so that user will not be forced to patch
OpenSSL in order to cross compile it.
I will be
Hello,
I did not see this patch was added to snapshot...
Is there anything more I can do? Is something missing?
Is something wrong? I will be glad to know about that.
Best Regards,
Alon Bar-Lev.
__
OpenSSL Project
Hello,
Succeeded in making openssl cross compile correctly!
./Configure --prefix=// --cross-compile-prefix=mingw32- shared mingw
Please also notice that --prefix must receive TWO slashes in order
to install to root (make install INSTALL_PREFIX=/tmp/w32)... Maybe
this also can be corrected.
The
Hello,
Succeeded in making openssl cross compile correctly!
./Configure --prefix=// --cross-compile-prefix=mingw32- shared mingw
Please also notice that --prefix must receive TWO slashes in order
to install to root (make install INSTALL_PREFIX=/tmp/w32)... Maybe
this also can be corrected.
But there is another problem which Unix-style Configure doesn't solve
now:
dll can include VERSION_INFO resource. Now Configure creates .rc file
only if IsMK1MF is set. I think that if we want to have native Win32
dll, we should include this resource, even if build environment is
completely
On 2006.10.25 at 13:36:11 +0200, Andy Polyakov wrote:
So we have to decide on unified naming convention for both MSC and
mingw. Suggestion is to embed version number into name, but remaining
questions are:
- do we still stick to 8.3 naming?
Really I think that time to forget 8.3 naming
I personally have no problems with that, but formally we should ask
ourselves what is the goal of this effort? To produce *some* .dll or to
produce *100% compatible replacement* .dll for MSC build? If latter,
then we have to get .def working. If former, we can as well settle for
--export-all.
On 2006.10.23 at 11:21:26 +0200, Andy Polyakov wrote:
Care to figure out and tell how to do it with windres and ld? I mean
It is quite simple. When I finish solving current dll name problem
(I.e. manage to do make and make test without manual dll renaming)
i'll do this.
On 2006.10.23 at 11:21:26 +0200, Andy Polyakov wrote:
But there is another problem which Unix-style Configure doesn't solve
now:
dll can include VERSION_INFO resource. Now Configure creates .rc file
only if IsMK1MF is set. I think that if we want to have native Win32
dll, we should
On Mon, 23 Oct 2006 16:24:00 +0400, Victor B Wagner said:
Here is preliminary patch to generate resource sections for DLLs.
I call it preliminary, because:
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build
On 2006.10.23 at 13:54:55 +0100, Martin Simmons wrote:
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and
ssl32.dll. Patch includes code to support this difference, but I'm
not absolutely sure it
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and
ssl32.dll. Patch includes code to support this difference, but I'm
not absolutely sure it belongs there.
BTW, what is the meaning of 32 in
On Mon, Oct 23, 2006, Victor B. Wagner wrote:
Here is preliminary patch to generate resource sections for DLLs.
I call it preliminary, because:
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and
On Mon, 23 Oct 2006 16:09:03 +0200, Andy Polyakov said:
1. DLL name issue is not permanentely settled. MSVC build creates
libeay32.dll and ssleay32.dll, and Mingw build crypto32.dll and
ssl32.dll. Patch includes code to support this difference, but I'm
not absolutely sure it
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 different ordinals], but don't do that, at
least not
So, if we write make rehash target following way:
http://cvs.openssl.org/chngview?cn=15632. a.
__
OpenSSL Project http://www.openssl.org
Development Mailing List
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
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
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
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
On 2006.10.17 at 19:40:05 +0200, Alon Bar-Lev wrote:
Hello,
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...
Before I making too much
On Thursday 19 October 2006 12:02, Victor B. Wagner wrote:
I do it routinely.
Thank you for your reply!
1. Modify Configure script, adding target
mingw-cross
(this all should go into one line)
mingw-cross, i586-mingw32msvc-gcc:-mno-cygwin -DL_ENDIAN
-fomit-frame-pointer -O3 -march=i486
Hi,
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...
Before I making too much modifications,
Have anyone succeeded in doing so?
On 10/18/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
The easier way probably is to modify the Configure script and then go
the standard Unix route of compiling. I know I've found (and used)
patches for doing this, googling for something like
mingw Configure OpenSSL
Thanks for reply.
But it
Hello,
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...
Before I making too much modifications,
Have anyone succeeded in doing so?
Best
58 matches
Mail list logo
