Minimal configuration
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 trouble deciding which "cpu/compiler" config to go with. I am using gcc and mips (not mipsel). I'm not worried about resources (have plenty of RAM). I'm only interested in verifying signatures. So some extra switches that strip out functions that handle encryption or signing would also be great. I am looking for the smallest libcrypt possible. Any advice would be appreciated. Thanks in advance. -- Grant Mills [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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 different ordinals], but don't do that, at > least not at present... A. Well I can recall asking that ages ago and at IIRC the reason was precisely that changes made might break binary compatibility. Although we don't guarantee binary compatibility across major versions we do across minor ones (unless there is a *very* good reason not to) and possibly adding functions in a minor release might break things. 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? Steve. -- Dr Stephen N. Henson. Email, S/MIME and PGP keys: see homepage OpenSSL project core developer and freelance consultant. Funding needed! Details on homepage. Homepage: http://www.drh-consultancy.demon.co.uk __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Source for entropy on Windows platforms with CryptoAPI installed
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 pseudo-random stream, but I wonder if it might make sense to try to make use of it the same way OpenSSL on UNIX uses /dev/urandom? No. /dev/urandom returns unique chunk for every read, while accessing the key in question does not change its value. Therefore it is not appropriate to use as if it was /dev/urandom. The value is changed upon calls to CryptoAPI, but then you get random data by CryptoAPI means and don't need to read the key value. BTW, I fail to understand why does the seed have to be exposed world-readable. I mean how do we know that exposing the seed to non-privileged adversary application does not compromise prng generator for other applications? For reference tightening ACL to limit access to privileged users does not seem to have side effects on non-privileged users. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1417] enhancement request: FAQ
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 cause SSL_CTX_use_certificate_chain_file to always fail. A work-around is to call ERR_clear_error() to clear the per-thread error queue before calling SSL_CTX_use_certificate_chain_file. I found the above reference only after having identified the problem. Could an entry be made in the FAQ identifying the problem, and the work-around? Thanks. == http://public.2idi.com/=titus __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
[openssl.org #1416] [PATCH] display UPN if in subjectAltName
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://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 WSAStartup.
As far as I can see wship6.dll for 2000 is
"don't-you-dare-to-use-it-in-production-environment" technology preview
thing and this is not going to change. So I'd say if somebody wants for
some twisted reason to experiment with IPv6 under 2000, they can as well
drop LoadLibrary("wship6.dll") into *their* application [if it's not
loaded automatically]. It really has to be twisted reason, because the
only reason you'd like to use it is for IPv6 development, but it's so
generalized that you just as well might use XP... I suggest we simply
omit this wship6.dll argument and concentrate on real question: do we go
for ws2_32 and imply that NT4/W98 are minimally required from now on? A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1400] spurious CRs in S/MIME clearsigned mails
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 -b) Recipient Windows box: - Windows 2000 sp4 - MS Outlook Express 6.00.2800.1106 On the Debian box, the mail is generated and sent with: | $ echo "some text" > textfile | $ openssl smime -sign -text \ | -signer ~/.smime/certificates/26f06522.0 \ | -inkey ~/.smime/keys/26f06522.0 \ | -in textfile \ | -out mailfile \ | -to testuser \ | -from "Bruno Kozlowski <[EMAIL PROTECTED]>" \ | -subject "test smime" | $ /usr/sbin/sendmail -t < mailfile# symlink to exim On the Windows box, MSOE fetches the mail directly from the Linux box, thru POP3, and fails signature verification. Following EOLs at each step: -1) OpenSSL generated mailfile has mixed EOLs: Most lines have LF, some lines CRLF (the 3 signed lines): | $ wc -l mailfile | 34 mailfile | $ cat -A mailfile | grep -c "\^M" | 3 -2) Exim's spool preserved same mixed EOLs: | # cat -A /var/spool/exim/input/1GarhL-0001Ve-00-D | grep -c "\^M" | 3 -3) Delivered to testuser's mailbox with same mixed EOLs: | # cat -A /var/spool/mail/testuser | grep -c "\^M" | 3 -4) Fetched to MSOE inbox as CRLF for most lines, and CRCRLF for the 3 signed lines: | $ cat -A Bote\ de\ rception.dbx | grep -c "\^M\^M\\$" | 3 -5) The message exported as *.eml gives mixed CRLF and CRCRLF (I gzipped and attached this .eml file for your experiments): | $ cat -A test\ smime.eml | grep -c "\^M\^M" | 3 -6) MSOE claims this message was falsified. -7) If I modify "test smime.eml" file to remove the 3 spurious CRs, canonicalizing all line endings to CRLF, then open the file in MSOE: Signature verification succeeds. Note I described the simplest setup, but various others produces the same CRCRLF problem. Like with an intermediate Exim smarthost, with Win98, or with a Redhat sending box (OpenSSL 0.9.8d, but unknown MTA). OTOS many others setups filter out spurious CRs, and so eliminate any consequence of the problem. Like with fetchmail on the path. Also note that OpenSSL verification seemingly works OK in all cases: LF, CRLF, CRCRLF, and even CRCRCRCRCRCRCRLF, in any mix from line to line, and running on Linux or Windows. Always successfull. > During the past weekend I have time to setup a test network: Thank you very much for your interest, Roumen. I suppose that in your setup the spurious CRs are filtred out at some stage? > In case of version >= 0.9.7d mail are generated with and without > openssl smime -crlfeol option. This -crlfeol option doesn't seem to help. It's not much documented (CHANGES file only), but the intended effect seems to be to end all lines in CRLF. Strangely some lines still end in LF alone: The To, From, and Subject headers, and the base64 lines encoding the smime.p7s file. I believe that all written EOLs should be consistent: All LF by default (on LF platforms); All CRLF with -crlfeol. Bye!Bruno. -- /* Bruno Kozlowski <[EMAIL PROTECTED]> */ __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 insist on
> bumping _WIN_WIN32 to 0x400. Shall we do that? I personally have no
> objections to that.
Me neither, but then again, I'm not a user nor am I maintainer of a
native Windows OpenSSL...
> DSO_global_lookup looks only through currently loaded dlls, and never
> attempts to load any new.
That's why I said I don't know if it would already work. It's possible
that wship6.dll is automatically loaded into the processes VM when
ws2_32.dll is loaded in which case DSO_global_lookup would just do the
"right thing"(tm).
> On bright side one can simply throw in
> LoadLibrary("wship6.dll") literally anywhere, e.g. next to WSAStartup. A.
Yup.
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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 add and test that? I've found simplier approach. There is linker option --export-all, which allows to make working DLL without .def files. 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. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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
b_sock.c I considered linking with wsock32 to be sufficient/appropriate
for following reason. Systems equipped with ws2_32.dll do have wsock32
too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning
that [legacy] application linked with wsock32 alone will actually bring
even ws2_32.dll into address space. Now note that b_sock.c makes
*global* lookups for getaddrinfo, meaning that application linked with
wsock32 alone will actually find getaddrinfo even if it resides in
ws2_32! So that the fact that latest headers [those defining struct
This is a very thin ice approach. When you use wsock32, it's using
Winsock 1.1. There are incompatibilities between Winsock 1.1 and
Winsock 2, which are solved by using different header files. Including
winsock.h and winsock2.h concurrently is wrong. It's also wrong to
include winsock.h when linking against ws2_32.dll and it's wrong to
include winsock2.h when linking against wsock32.dll.
For instance, several socket options have different values. As an
example, IP_TOS is defined as the value 3 under Winsock 2, but it was
defined as the value 8 under Winsock 1.1.
Yes, it *is* thin ice approach, which is why I said that it requires
*discipline*. The kind of discipline that requires you to explicitly
verify that common structures and constants _actually used_ in your code
are the same in old and new headers. But this was actually *done* for
b_sock.c, which is why I *dared* to include new header and link old
library. I mean it's admittedly daring, but it's not groundless in this
particular case:-)
addrinfo] are included, but elder library is linked with is actually
intentional. Yes, it requires certain programming discipline, but it's
[considered] doable. As for IPv6. If w2k supports it only through
additional library, I'd say "is it really a problem not to have IPv6 on
pre-XP?"
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. I don't
see it as bigger problem (anybody running IPv6 on 2000 raise your
hands), but anyway...
As I said in another mail,
Winsock 2 is by default available since Windows 95 OSR2 and NT4.
Keep in mind 0x333, it's 3.51. If we switch to ws2_32, I'd insist on
bumping _WIN_WIN32 to 0x400. Shall we do that? I personally have no
objections to that.
It's really not that hard. Always use ws2_32.dll instead of wsock32.dll,
never include winsock.h and, last but not least, if loading getaddrinfo/
freeaddrinfo from ws2_32.dll fails, try again by loading it from
wship6.dll. If that fails, IPv6 is not available. However, I'm not
sure if the DSO_global_lookup approach also covers wship6.dll
automatically on W2K. Somebody would have to try it.
DSO_global_lookup looks only through currently loaded dlls, and never
attempts to load any new. On bright side one can simply throw in
LoadLibrary("wship6.dll") literally anywhere, e.g. next to WSAStartup. A.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
c_rehash with cross-compiling or ActiveState perl (Re: Cross compile OpenSSL in Linux using MinGW32)
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 OpenSSL during build stage (of course, for
> cross-builds only).
More detailed problem with c_rehash under Win32:
I. Running make rehash in Win32/msys environment using ActiveState perl
1. msys shell pwd command without -W option outputs path which looks
like /h/src/openssl, which confuses ActiveState Perl. It understands
only h:/src/openssl.
2. ActiveState perl doesn't consider util/opensslwrap.sh executable
and reports 'openssl' command not found. Really opensslwrap script is
not needed under win32, because openssl.exe would always search for DLL
in the directory where it resides itself, and DLLs are copied there
during build process. File with .exe suffix is recongnized as
executable, so passing OPENSSL="`pwd -W`/apps/openssl.exe" to c_rehash makes
it work under msys+AS perl environment. But due to problem 3 it only
reports a lot of "file not found" errors.
3. c_rehash uses signle quotes around filename to pass certificate name
to openssl x509 -hash
my ($hash, $fprint) = `"$openssl" x509 -hash -fingerprint -noout -in
"$fname"`;
It doesn't work with ActiveState perl (which is most widespread native
Win32 perl implementation). Really, it doesn't work with any
implementation of Perl which uses native Windows command interpreter to
handle backtick commands. Changing single quotes there to double quotes
makes command more universal.
II. Running c_rehash on non-windows build platform.
It only requires way to override OPENSSL variable passed to c_rehash.
Something like HOST_OPENSSL=/usr/bin/openssl
So, if we write make rehash target following way:
rehash: rehash.time
rehash.time: certs
(if [ $$OSTYPE = msys ]; then \
OPENSSL=$${HOST_OPENSSL:-`pwd -W`/apps/openssl.exe};\
else\
OPENSSL=$${HOST_OPENSSL:-`pwd`/util/opensslwrap.sh};\
fi;\
OPENSSL_DEBUG_MEMORY=on; \
echo $$OPENSSL;\
export OPENSSL OPENSSL_DEBUG_MEMORY; \
$(PERL) tools/c_rehash certs)
touch rehash.time
and change signle quotes to double in the c_rehash
functions link_hash_cert and link_hash_crl (this is a bit tricky because need
to escape double quotes properly, counting all rounds of substitution which can
occur),
this would work in msys, and also would allow to make rehash on cross-build
platform by adding HOST_OPENSSL=/usr/bin/openssl (or whereever your native
openssl binary is) when doing make.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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 that one needs to generate .def file as > well? Care to add and test that? I've found simplier approach. There is linker option --export-all, which allows to make working DLL without .def files. This I've tested. Probably some eariler version of Mingw32 has this option on by default, and so it was assumed that correct DLLs can be build without any extra effort. Really, .def files are much more flexible thing than just exporting all public symbol as Unix .so files do, but mkdef.pl really does almost same as --export-all. And mkdef.pl needs considerable modification to work correctly with Unix-style Configure and mingw32. Problem is that .def file mentions DLL name which is than used by import libraries to find DLL upon loading. So, this name have to be cryptoeay32-.dll, not just LIBEAY32 as mkdef.pl now generates. In my modified makefiles for 0.9.8 I'm postprocessing def files with perl. This is way too complicated, and doesn't do any better thing than just adding -Wl,--export-all to shlib linker command line for mingw target. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 versioning. Upon latest modifications to > b_sock.c I considered linking with wsock32 to be sufficient/appropriate > for following reason. Systems equipped with ws2_32.dll do have wsock32 > too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning > that [legacy] application linked with wsock32 alone will actually bring > even ws2_32.dll into address space. Now note that b_sock.c makes > *global* lookups for getaddrinfo, meaning that application linked with > wsock32 alone will actually find getaddrinfo even if it resides in > ws2_32! So that the fact that latest headers [those defining struct This is a very thin ice approach. When you use wsock32, it's using Winsock 1.1. There are incompatibilities between Winsock 1.1 and Winsock 2, which are solved by using different header files. Including winsock.h and winsock2.h concurrently is wrong. It's also wrong to include winsock.h when linking against ws2_32.dll and it's wrong to include winsock2.h when linking against wsock32.dll. For instance, several socket options have different values. As an example, IP_TOS is defined as the value 3 under Winsock 2, but it was defined as the value 8 under Winsock 1.1. > addrinfo] are included, but elder library is linked with is actually > intentional. Yes, it requires certain programming discipline, but it's > [considered] doable. As for IPv6. If w2k supports it only through > additional library, I'd say "is it really a problem not to have IPv6 on > pre-XP?" A. Seriously, I'd consider Winsock 1.1 as the one which should be left behind, rather than Windows 2000 users. As I said in another mail, Winsock 2 is by default available since Windows 95 OSR2 and NT4. Even for the original non-OSR2 release of Windows 95 is a Microsoft package with a Winsock2 implementation available. On the other hand, Windows 2000 is still officially supported by Microsoft, in contrast to Windows 95 and, FWIW, wsock32.dll. It's really not that hard. Always use ws2_32.dll instead of wsock32.dll, never include winsock.h and, last but not least, if loading getaddrinfo/ freeaddrinfo from ws2_32.dll fails, try again by loading it from wship6.dll. If that fails, IPv6 is not available. However, I'm not sure if the DSO_global_lookup approach also covers wship6.dll automatically on W2K. Somebody would have to try it. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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 add and test that? 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 at present... A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 for winsock versioning. Upon latest modifications to > b_sock.c I considered linking with wsock32 to be sufficient/appropriate > for following reason. Systems equipped with ws2_32.dll do have wsock32 > too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning > that [legacy] application linked with wsock32 alone will actually bring > even ws2_32.dll into address space. Now note that b_sock.c makes > *global* lookups for getaddrinfo, meaning that application linked with Hmm, actually -lws2_32 is not strictly neccessary. Are there tests for IPV6 in BIO in the test suite? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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" Winsock 2 > > > application should include winsock2.h and ws2tcpip.h. > > > > So, it is line 455 in e_os.h which is offending, not line 278? > > Line 455 looks wrong to me. winsock2.h is already included in line 277 > so I don't see how another include of winsock.h in line 455 could be > right. Further investigation shows that it is OK. Winsock.h wouldn't be included if winsock2.h already included. Problem was in other place File ssl/ssl_sess.c includes before "ssl_locl.h", and rand.h includes windows.h and windows.h includes winsock.h if winsock2 wasn't already included. So, just changing order of rand.h and ssl_locl.h ssl_sess.c, changing order of openssl/engine.h and apps.h in apps/apps.c, and changing order of openssl/rand.h and ../e_os.h in test/randtest.c fixes this problem __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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, AFAICS. > > Implementing of dynamic loading by hand is tricky thing anyway. Huh? > One have to declare function pointers and provide code which would fill > them with correct value. Which is already done in crypto/bio/b_sock.c. Did you look into the code? > And this code should be clever enough to find > appropriate DLL (provided that most Windows systems out there have > both). LoadLibrary? That's nothing new and already used in crypto/dso/dso_win32.c. ws2_32.dll exists on all systems starting with Windows 95 OSR2, but that doesn't mean the IPv6 functions are available. On Windows 2000, IPv6 is only available if wship6.dll is installed. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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
===
RCS file: /cvs-openssl/openssl/Configure,v
retrieving revision 1.541
diff -u -r1.541 Configure
--- Configure 17 Oct 2006 13:38:08 - 1.541
+++ Configure 20 Oct 2006 11:49:31 -
@@ -475,7 +475,7 @@
"BC-32","bcc32WIN32::BN_LLONG DES_PTR RC4_INDEX
EXPORT_VAR_AS_FN:${no_asm}:win32",
# MinGW
-"mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a",
+"mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lws2_32 -lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a",
# UWIN
"UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${no_asm}:win32",
@@ -930,7 +930,6 @@
my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
-$IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys());
$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq
"mingw");
$exe_ext=".pm" if ($target =~ /vos/);
@@ -1832,10 +1831,4 @@
return $errorcnt;
}
-# Attempt to detect MSYS environment
-sub is_msys
- {
- return 1 if (exists $ENV{"TERM"} && $ENV{"TERM"} eq "msys");
- return 0;
- }
Index: Makefile.shared
===
RCS file: /cvs-openssl/openssl/Makefile.shared,v
retrieving revision 1.57
diff -u -r1.57 Makefile.shared
--- Makefile.shared 20 May 2006 08:52:34 - 1.57
+++ Makefile.shared 20 Oct 2006 11:49:31 -
@@ -7,6 +7,7 @@
# CC contains the current compiler. This one MUST be defined
CC=cc
+NM=nm
CFLAGS=$(CFLAG)
# LDFLAGS contains flags to be used when temporary object files (when building
# shared libraries) are created, or when an application is linked.
@@ -101,7 +102,7 @@
LIBDEPS="$${LIBDEPS:-$(LIBDEPS)}"; \
SHAREDCMD="$${SHAREDCMD:-$(CC)}"; \
SHAREDFLAGS="$${SHAREDFLAGS:-$(CFLAGS) $(SHARED_LDFLAGS)}"; \
-nm -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' > lib$(LIBNAME).exp; \
+$(NM) -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' >
lib$(LIBNAME).exp; \
LIBPATH=`for x in $$LIBDEPS; do if echo $$x | grep '^ *-L' > /dev/null
2>&1; then echo $$x | sed -e 's/^ *-L//'; fi; done | uniq`; \
LIBPATH=`echo $$LIBPATH | sed -e 's/ /:/g'`; \
LD_LIBRARY_PATH=$$LIBPATH:$$LD_LIBRARY_PATH \
Index: apps/apps.c
===
RCS file: /cvs-openssl/openssl/apps/apps.c,v
retrieving revision 1.114
diff -u -r1.114 apps.c
--- apps/apps.c 12 May 2006 17:11:58 - 1.114
+++ apps/apps.c 20 Oct 2006 11:49:32 -
@@ -126,6 +126,9 @@
#include
#include
#include
+#define NON_MAIN
+#include "apps.h"
+#undef NON_MAIN
#ifndef OPENSSL_NO_ENGINE
#include
#endif
@@ -134,9 +137,6 @@
#endif
#include
-#define NON_MAIN
-#include "apps.h"
-#undef NON_MAIN
#ifdef _WIN32
static int WIN32_rename(const char *from, const char *to);
Index: crypto/bio/b_sock.c
===
RCS file: /cvs-openssl/openssl/crypto/bio/b_sock.c,v
retrieving revision 1.46
diff -u -r1.46 b_sock.c
--- crypto/bio/b_sock.c 11 Apr 2006 21:34:18 - 1.46
+++ crypto/bio/b_sock.c 20 Oct 2006 11:49:33 -
@@ -60,6 +60,7 @@
#include
#include
#define USE_SOCKETS
+#include "e_os.h"
#include "cryptlib.h"
#include
#if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_BSDSOCK)
Index: crypto/rand/randtest.c
===
RCS file: /cvs-openssl/openssl/crypto/rand/randtest.c,v
retrieving revision 1.8
diff -u -r1.8 randtest.c
--- crypto/rand/randtest.c 28 Aug 2005 22:49:55 - 1.8
+++ crypto/rand/randtest.c 20 Oct 2006 11:49:37 -
@@ -58,9 +58,9 @@
#include
#include
+#include "../e_os.h"
#include
-#include "../e_os.h"
/* some FIPS 140-1 random number test */
/* some simple tests */
Index: engines/ccgost/gost_eng.c
===
RCS file: /cvs-openssl/openssl/engines/ccgost/gost_eng.c,v
retrieving revision 1.2
diff -u -r1.2 gost_eng.c
--- engines/ccgost/gost_eng.c 21 Sep 2006 13:24:46 - 1.2
+++ engines/ccgost/gost_eng.c 20 Oct 2006 11:49:39 -
@@ -141,20 +141,11 @@
return ret;
Re: Cross compile OpenSSL in Linux using MinGW32
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 avoid name clash between our pointers and functions, declared in that file. After examining few test Win2000 systems around there, I'we found that they all have ws2_32.dll. It was included in some ServicePack. Moreover, mingw runtime includes libws2_32.a (equivalent of MS ws2_32.lib), and not libwship6.a. So it seems that it is relatively harmless to link with -lws2_32. May be that for NT4 and 9x it would be required to make separate binary distribution with IPV6 disabled. But I don't think that it is worth effort to find out whether IPV6 is available at runtime. 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 b_sock.c I considered linking with wsock32 to be sufficient/appropriate for following reason. Systems equipped with ws2_32.dll do have wsock32 too, and this wsock32.dll is actually linked with ws2_32.dll. Meaning that [legacy] application linked with wsock32 alone will actually bring even ws2_32.dll into address space. Now note that b_sock.c makes *global* lookups for getaddrinfo, meaning that application linked with wsock32 alone will actually find getaddrinfo even if it resides in ws2_32! So that the fact that latest headers [those defining struct addrinfo] are included, but elder library is linked with is actually intentional. Yes, it requires certain programming discipline, but it's [considered] doable. As for IPv6. If w2k supports it only through additional library, I'd say "is it really a problem not to have IPv6 on pre-XP?" A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
PATCH (Re: Cross compile OpenSSL in Linux using MinGW32)
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 to link IPV6 stuff (not
compatible with old versions of windows, but my MingW32 runtime
doesn't have libwship6.a). I've found that on our test Win2000
system WINNT/System32 folder contains ws2_32.dll which was brought
by some service pack
1.3. Remove setting of IsMK1MF variable to 1 in case of mingw build
(as suggested by Andy Polyakov above in the thread)
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.
3. ssl/ssl_sess.c
Move #include "ssl_locl.h" above
#include
because ssl_locl.h includes e_os.h, which includes winsock2 and
ws2tcp.h, and rand.h includes windows.h, which includes winsock.h if
winsock2.h wasn't previously included
4. crypto/bio/b_sock.c
add #include "e_os.h" to provide neccessary definitions for IPV6
stuff
5. engines/ccgost/gost_eng.c
Remove __declspec(dllexport) before IMPLEMENT_DYNAMIC_CHECK_FN
and IMPLEMENT_DYNAMIC_BIND_FN macros. These macros now include
OPENSSL_EXPORT which expands to appropriate declspec under Win32.
Index: Configure
===
RCS file: /cvs-openssl/openssl/Configure,v
retrieving revision 1.541
diff -u -r1.541 Configure
--- Configure 17 Oct 2006 13:38:08 - 1.541
+++ Configure 20 Oct 2006 11:37:38 -
@@ -475,7 +475,7 @@
"BC-32","bcc32WIN32::BN_LLONG DES_PTR RC4_INDEX
EXPORT_VAR_AS_FN:${no_asm}:win32",
# MinGW
-"mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a",
+"mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lws2_32 -lwsock32 -lgdi32:BN_LLONG
${x86_gcc_des} ${x86_gcc_opts}
EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a",
# UWIN
"UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des}
${x86_gcc_opts}:${no_asm}:win32",
@@ -930,7 +930,6 @@
my $IsMK1MF=scalar grep /^$target$/,@MK1MF_Builds;
-$IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys());
$exe_ext=".exe" if ($target eq "Cygwin" || $target eq "DJGPP" || $target eq
"mingw");
$exe_ext=".pm" if ($target =~ /vos/);
@@ -1832,10 +1831,4 @@
return $errorcnt;
}
-# Attempt to detect MSYS environment
-sub is_msys
- {
- return 1 if (exists $ENV{"TERM"} && $ENV{"TERM"} eq "msys");
- return 0;
- }
Index: Makefile.shared
===
RCS file: /cvs-openssl/openssl/Makefile.shared,v
retrieving revision 1.57
diff -u -r1.57 Makefile.shared
--- Makefile.shared 20 May 2006 08:52:34 - 1.57
+++ Makefile.shared 20 Oct 2006 11:37:38 -
@@ -7,6 +7,7 @@
# CC contains the current compiler. This one MUST be defined
CC=cc
+NM=nm
CFLAGS=$(CFLAG)
# LDFLAGS contains flags to be used when temporary object files (when building
# shared libraries) are created, or when an application is linked.
@@ -101,7 +102,7 @@
LIBDEPS="$${LIBDEPS:-$(LIBDEPS)}"; \
SHAREDCMD="$${SHAREDCMD:-$(CC)}"; \
SHAREDFLAGS="$${SHAREDFLAGS:-$(CFLAGS) $(SHARED_LDFLAGS)}"; \
-nm -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' > lib$(LIBNAME).exp; \
+$(NM) -Pg $$SHOBJECTS | grep ' [BDT] ' | cut -f1 -d' ' >
lib$(LIBNAME).exp; \
LIBPATH=`for x in $$LIBDEPS; do if echo $$x | grep '^ *-L' > /dev/null
2>&1; then echo $$x | sed -e 's/^ *-L//'; fi; done | uniq`; \
LIBPATH=`echo $$LIBPATH | sed -e 's/ /:/g'`; \
LD_LIBRARY_PATH=$$LIBPATH:$$LD_LIBRARY_PATH \
Index: crypto/bio/b_sock.c
===
RCS file: /cvs-openssl/openssl/crypto/bio/b_sock.c,v
retrieving revision 1.46
diff -u -r1.46 b_sock.c
--- crypto/bio/b_sock.c 11 Apr 2006 21:34:18 - 1.46
+++ crypto/bio/b_sock.c 20 Oct 2006 11:37:38 -
@@ -60,6 +60,7 @@
#include
#include
#define USE_SOCKETS
+#include "e_os.h"
#include "cryptlib.h"
#include
#if defined(OPENSSL_SYS_NETWARE) && defined(NETWARE_BSDSOCK)
Index: ssl/ssl_sess.c
===
RCS file: /cvs-openssl/openssl/ssl/ssl_sess.c,v
retrieving revision 1.62
diff -u -r1.62 ssl_sess.c
---
Re: Cross compile OpenSSL in Linux using MinGW32
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 is tricky thing anyway. One have to declare function pointers and provide code which would fill them with correct value. And this code should be clever enough to find appropriate DLL (provided that most Windows systems out there have both). This code should be somehow called. And since we have to include ws2tcpip.h anyway for structure definitions, we should provide way to avoid name clash between our pointers and functions, declared in that file. After examining few test Win2000 systems around there, I'we found that they all have ws2_32.dll. It was included in some ServicePack. Moreover, mingw runtime includes libws2_32.a (equivalent of MS ws2_32.lib), and not libwship6.a. So it seems that it is relatively harmless to link with -lws2_32. May be that for NT4 and 9x it would be required to make separate binary distribution with IPV6 disabled. But I don't think that it is worth effort to find out whether IPV6 is available at runtime. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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. > > So, it is line 455 in e_os.h which is offending, not line 278? Line 455 looks wrong to me. winsock2.h is already included in line 277 so I don't see how another include of winsock.h in line 455 could be right. > > And here's another problem. The functions getaddrinfo, getnameinfo and > > freeaddrinfo are only exported by ws2_32.dll beginning with Windows XP. > > There's an earlier implementation for Windows 2000 which is exported by > > a DLL called wship6.dll. There's no v6 for 9x or NT4. Consequentially, > > on native Windows (not Cygwin) the functions should not be linked > > against, but instead corresponding function pointers should be loaded at > > runtime from either ws2_32.dll or wship6.dll using > > LoadLibrary/GetProcAddress. > > 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. Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 due to
> multiple unresolved symbols. This is why proper .def file is needed.
I found way to live without proper .def file.
diff -r1.541 Configure
478c478
< "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
-Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG ${x86_gcc_des}
${x86_gcc_opts} EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
-DOPENSSL_USE_APPLINK:-mno-cygwin -shared:.dll.a",
---
> "mingw", "gcc:-mno-cygwin -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486
> -Wall -D_WIN32_WINNT=0x333:::MINGW32:-lwsock32 -lgdi32:BN_LLONG
> ${x86_gcc_des} ${x86_gcc_opts}
> EXPORT_VAR_AS_FN:${x86_coff_asm}:win32:cygwin-shared:-D_WINDLL
> -DOPENSSL_USE_APPLINK:-Wl,--export-all -mno-cygwin -shared:.dll.a",
With this option added, shared build completes successfully.
__
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 applications. A "modern" Winsock 2 > application should include winsock2.h and ws2tcpip.h. So, it is line 455 in e_os.h which is offending, not line 278? > And here's another problem. The functions getaddrinfo, getnameinfo and > freeaddrinfo are only exported by ws2_32.dll beginning with Windows XP. > There's an earlier implementation for Windows 2000 which is exported by > a DLL called wship6.dll. There's no v6 for 9x or NT4. Consequentially, > on native Windows (not Cygwin) the functions should not be linked > against, but instead corresponding function pointers should be loaded at > runtime from either ws2_32.dll or wship6.dll using > LoadLibrary/GetProcAddress. So, use IPV6 on native windows requires considerable changes anyway? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 earlier I'd actually prefer this, i.e. mingw build to > > *require* Unix emulation environment. Is it really unreasonable? In > > I think it is reasonable. Unless it would break some non-gcc build > (i.e Visual Studio, Borland or some netware one). > > > other words I'd simply scrap "$IsMK1MF=1 if ($target eq "mingw" && $^O > > ne "cygwin" && !is_msys());" line for good. A. > > Now, some further info. > > Next problem I've encountered building current CVS state of 0.9.9 > was error in e_os.h > "ws2tcpip.h is not compatible with winsock.h". It was fixed by removal > of #include from mentioned file. > > 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 applications. A "modern" Winsock 2 application should include winsock2.h and ws2tcpip.h. > Next problem was "dereferencing pointer to incomplete type" in > line 728 of b_sock.c. It seems that symbol AF_INET6 is somehow declared > (may be cross-compiler picks some native header), but appropriate > structures are not defined. I've temporary solved this problem by > replacing The IPv6 stuff is defined in ws2tcpip.h... And here's another problem. The functions getaddrinfo, getnameinfo and freeaddrinfo are only exported by ws2_32.dll beginning with Windows XP. There's an earlier implementation for Windows 2000 which is exported by a DLL called wship6.dll. There's no v6 for 9x or NT4. Consequentially, on native Windows (not Cygwin) the functions should not be linked against, but instead corresponding function pointers should be loaded at runtime from either ws2_32.dll or wship6.dll using LoadLibrary/GetProcAddress. HTH, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 build to > *require* Unix emulation environment. Is it really unreasonable? In I think it is reasonable. Unless it would break some non-gcc build (i.e Visual Studio, Borland or some netware one). > other words I'd simply scrap "$IsMK1MF=1 if ($target eq "mingw" && $^O > ne "cygwin" && !is_msys());" line for good. A. Now, some further info. Next problem I've encountered building current CVS state of 0.9.9 was error in e_os.h "ws2tcpip.h is not compatible with winsock.h". It was fixed by removal of #include from mentioned file. I'm not an expert on Win32 tcpip history and cannot tell whether it is problem of my mingw32 runtime headers or something also. Next problem was "dereferencing pointer to incomplete type" in line 728 of b_sock.c. It seems that symbol AF_INET6 is somehow declared (may be cross-compiler picks some native header), but appropriate structures are not defined. I've temporary solved this problem by replacing #if defined(OPENSSL_SYS_BEOS_BONE) /* BONE's IP6 support is incomplete */ #undef AF_INET6 #endif with #if defined(OPENSSL_SYS_BEOS_BONE) || defined(_WIN32) /* BONE's IP6 support is incomplete */ #undef AF_INET6 #endif in line 90 of crypto/bio/b_sock.c. After this static build succeeds. If I attempt to do ./Configure mingw shared and then make CC=i586-mingw32msvc-gcc RANLIB=i586-mingw32msvc-ranlib\ 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 due to multiple unresolved symbols. This is why proper .def file is needed. I've not tried ./Configure mingw shared zlib, because I don't have win32 zlib develpment files on machine where I'm doing my experiments. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 tree, I got problem with line 933 of Configure script: $IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys()); Of course it doesn't recongnize that it should not set IsMK1MF to 1 when doing Linux-hosted build. Same problem occurs when doing build with Cygwin compiler, but non-cygwin (i.e. ActiveState) Perl. And we use this setup on our win32 test machine, so this line was patched in Configure script too. We have replaced this line in our patched Configure with my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A VC-NT VC-CE VC-WIN32 BC-32 OS2-EMX netware-clib netware-libc netware-libc-bsdsock); sMK1MF=scalar grep /^$target$/,@MK1MF_Builds; 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 build to *require* Unix emulation environment. Is it really unreasonable? In other words I'd simply scrap "$IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys());" line for good. A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 Configure. When I've restarted build with unmodified 0.9.9 source tree, I got problem with line 933 of Configure script: $IsMK1MF=1 if ($target eq "mingw" && $^O ne "cygwin" && !is_msys()); Of course it doesn't recongnize that it should not set IsMK1MF to 1 when doing Linux-hosted build. Same problem occurs when doing build with Cygwin compiler, but non-cygwin (i.e. ActiveState) Perl. And we use this setup on our win32 test machine, so this line was patched in Configure script too. We have replaced this line in our patched Configure with my @MK1MF_Builds=qw(VC-WIN64I VC-WIN64A VC-NT VC-CE VC-WIN32 BC-32 OS2-EMX netware-clib netware-libc netware-libc-bsdsock); sMK1MF=scalar grep /^$target$/,@MK1MF_Builds; 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). Function is_msys() as it written, never give correct result in our msys environments. If I run msys rxvt terminal emulator, TERM is "xterm", if I start msys shell in console window, it is for some reason "cygwin". Really, I think checking for existense of TERM variable is enough to determine that there is some Unix emulation environment. At least, it can be documented, and user who wants MK1MF build might explicitely unset this variable during Configure stage without any harm. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: Cross compile OpenSSL in Linux using MinGW32
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 -DL_ENDIAN > > 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 after doing make on linux system, it complains about "certificate rehashing skipped, openssl program not available". I've tried with 0.9.8 I'd repeat this with current development tree. > question is if it's possible to achieve the goal without adding extra > target... First of all, nm program name should be overriden to, but openssl Makefile.shared do not define variable for nm, and hardcodes program name instead. Now make complains about "file format not recognized" multiple times. 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 OpenSSL during build stage (of course, for cross-builds only). If people are interesting, I can publish somewhere results of nightly build on our test farm. Now we have following platforms 1. Various Linux distributions 2. FreeBSD 4.x, 5.x and 6.x on i386, FreeBSD 6.x on AMD 64 3. Solaris x86 8, 9 and 10 4. Solaris Sparc 10 (both 32-bit and 64-bit build) 5. Mingw build on Win32 system using Cygwin compiler and ActiveState Perl. We can add build with real mingw compiler on Win32 and linux-hosted build with mingw compiler. > >2. Modify Makefile shared so it would call > >util/mkdef.pl script. and add generated .def file to linking command > >Note that DEF file should contain correct DLL name, not just crypteay32 > >mingw32 builds libcrypto-0.9.8.dll, and this name should exactly appear > >in the .def file > > If it's reusable on real mingw and cygwin, then it makes sense to throw > it in. A. It is applicable at least to real mingw. I don't remember exact circumstances, but when we've switched from 0.9.8a to 0.9.8b we have problems with deploying mingw32 build (which is used in production environment now) and problem was solved by using proper .def files. It is applicable for both native and linux-hosted builds (although we never tested mingw build with cygwin compiler in production environment). It was related to changes in DSO_WIN32 (which began to find engine modules correctly in this release). __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
Re: [openssl.org #1413] v0.9.7l: some comments
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 for say i686. cmov in particular is bad for P4 performance for example. Also note that assembler codes detect architecture and modify behavior at run-time [though not if you compile for i386]. But do you really support i386? With modern bloatware it would be pretty much really useless. It makes more sense to have separate i386-oriented "slim" distribution, than target i386 in prime line... The dynamic linker will then pick up the right version depending on the cpu you use. We do the same for alpha for ev4 and ev5, Doesn't it make more sense to tell apart pre-ev6 and ev6, because byte access access instructions were added in ev6? This would actually be noticeable in OpenSSL context. and sparc for v8 and v9. If you care about i386, why not care about sparcv7:-) A. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager [EMAIL PROTECTED]
