Hi Linda,
OpenSSL compiles perfectly with/on the target mingw64 - there is however
a minor issue (and fix) that isn't (yet) committed in the official repo.
See RT #3454 on http://rt.openssl.org/Ticket/Display.html?id=3454 for
an issue when compiling with the enable-ec_nistp_64_gcc_128 flag
Hope this helps,
Peter Mosmans
On 10-08-2014 21:40, Linda Zhang wrote:
> Hi Support and Gisle,
>
>> "Support" wrote:
>> Have you tried running the 'regular' commands ?
>> Perl Configure mingw
>> make depend
>> make
>> make report
>> As far as I know these always work on msys - there is no need to run the
>> ms/mingw32.bat script.
>> To get the shared libraries you need to add the shared flag to
>> Configure, eg.
>> perl Configure mingw shared
>> Hope this helps,
> Thank you for help.
>
> I've tried your commands and it works well, generating the same file names as
> VC-WIN32 does, for example ssleay32.dll instead of libssl32.dll from
> ms\mingw32.bat but it's undocumented for shared library.
> ("perl Configure mingw shared")
>
> Indeed, OpenSSL is poor documented. I've been using OpenSSL since 0.9.8. The
> only way suggested compiling on MinGW is ms\mingw32.bat, and this command
> generates shared libraries by default, and the "shared" parameter is not
> documented at all. Later, OpenSSL goes to 1.0.0, and the way to compile on
> MinGW switched to MSYS, but I can't find this important change from CHANGELOG
> at all. Also ./configure doesn't generate shared libraries by default, you
> must add "shared" parameter manually, but the parameter is also not documented
> at all.
>
> Now I suggest to document it in INSTALL.W32 file, GNU C (MinGW/MSYS) section
> as
> below:
>
> GNU C (MinGW/MSYS)
> -------------
> .......
>
> * Compile OpenSSL:
>
> - $ ./config
> + $ ./config shared
> [...]
> $ make
> [...]
> $ make test
>
> This will create the library and binaries in root source directory
> and openssl.exe application in apps directory.
>
> + Do not run ms\mingw32.bat to compile OpenSSL 1.x. It's only for legacy
> + OpenSSL 0.9.x, (and will be removed in future releases?)
>
> It is also possible to cross-compile it on Linux by configuring
> with './Configure --cross-compile-prefix=i386-mingw32- mingw ...'.
> 'make test' is naturally not applicable then.
> .......
>
> --------------
> After then, it will be clear enough to everyone who compiles OpenSSL on MinGW.
>
> Besides, I found a target "mingw64" in Configure file, but not documented in
> INSTALL.W64. Could anyone test the target if it's available?
>
>> "Gisle" wrote:
>> OpenSSL (on Windows at least) is close to the "package from hell". Someone
>> here
>> remember gettext? For example; a little error like this in
>> crypto/threads/th-lock.c:
>>
>> 89: void CRYPTO_thread_cleanup(void);
>> ...
>> 108: #ifdef OPENSSL_SYS_WIN32
>> ...
>> 127: static void CRYPTO_thread_cleanup(void)
>> ...
>>
>> (a 'static' following a 'non-static' function). Shit like that has gone
>> unnoticed
>> for years because that particular combo has not been compiled by many
>> users/compilers. I'm not sure why. But the code-path for Solaris and Irix
>> are
>> correct. One would assume Windows was much more popular than those
>> dinosaurs. Go figure!
> Also, OpenSSL is poor coded. To avoid <winsock2.h> and <windows.h> conflict
> problem, we should unify the order of header files in a good standard, but not
> evading the problem by adding a ridiculous macro. What to do if OpenSSL will
> use a feature LEAN_AND_MEANed by the macro in the future? Of course the
> ultimate source of the problem comes from M$ who defined a ridiculous order
> of header files. By normal design, <winsock2.h> should be included by
> <windows.h>, but M$ made it vice versa.
>
> If every contributer writes CHANGELOG and documents their code, the project
> will be better.
>
> Regards,
> Linda Zhang
>
>>> Hi ,
>>>
>>> Building in MSYS by "./config" and "make" works, but I can't find
>>> libeay32.dll
>>> and libssl32.dll when compilation finishes.
>>>
>>> So, I build openssl with command line "ms\mingw32.bat". It seems there must
>>> be
>>> something wrong that it didn't pass CFLAGS configured by "perl Configure
>>> mingw" to
>>> gcc. Instead, the "ms\mingw32.bat" uses CFLAGS defined in
>>> "util/pl/Mingw32.pl".
>>> Of course there is no -DWIN32_LEAN_AND_MEAN. After applying another patch
>>> in the
>>> attachment to the original openssl 1.0.1i, "ms\mingw32.bat" works without
>>> error.
>>>
>>> Maybe we should fix something of mingw building scripts?
>>>
>>> Regards,
>>> Linda Zhang
>>>
>>>
>>>
>>> 发件人： Gisle Vanem
>>> 发送时间： 2014-08-10 19:45:04
>>> 收件人： [email protected]; [email protected]
>>> 抄送：
>>> 主题： Re: [PATCH] Make openssl 1.0.1 compilable on MinGW
>>>
>>>> "Linda Zhang" <[email protected]> wrote:
>>>>> 2. There is a conflict of the order of winsock2.h and windows.h in some
>>>>> source
>>>>> files so that the compiler shows error messages:
>>>>> ========
>>>>> #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h
>>>>> instead."
>>>>> mingw32-make: *** [tmp\t1_lib.o] Error 1
>>>>> ========
>>>>> The bug is introduced by the include of <windows.h> in the file
>>>>> "crypto/rand/rand.h" and finally raised by the inappropriate include
>>>>> order in
>>>>> some source files.
>>>> Are you sure '-DWIN32_LEAN_AND_MEAN' is in your CFLAGS?
>>>> (it should be AFAICR). Adding this would ensure <winsock.h> is
>>>> *not* included in <windows.h>. IMHO it would be cleaner to do this
>>>> and make sure <winsock2.h> + <ws2tcpip.h> gets included explicitly.
>>>> --gv
> :��I"Ϯ��r�m���� (���Z+�7�zZ)���1���x ��h���W^��^��%��
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [email protected]
