Closing as well according to #1552
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [E
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 Ma
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 proced
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 proced
> 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 up
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 up
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
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 Re
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
openssl-S
[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 Proj
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 glad
Hello,
Can I further help regarding this issue?
Is something wrong with the patch? I will fix per your comments.
Best Regards,
Aon Bar-Lev.
__
OpenSSL Project http://www.openssl.org
Development M
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.
The
On Saturday 21 October 2006 01:34, Dr. Stephen Henson wrote:
> BTW on the subject of cross compiling what are the thoughts on
> making this easier by adding a command line option to Configure
> which inserts a prefix to the relevant compiler tools?
Hello,
Tried to use the new cross of openssl-SN
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 nam
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 Uni
> 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 ab
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
>
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 t
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 su
> 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 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 sh
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.
___
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.20 at 15:10:06 +0200, Andy Polyakov wrote:
> 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
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
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
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 a
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 ment
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 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
and #include "apps.h" in apps/apps.c
and order of and "../e_os.h" in test/randtest.c
Updated patch attached.
Index: Configure
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 libraries
36 matches
Mail list logo
