>>> in the file crypto/sha/sha.h there is this line: >>> >>> #if (defined(_WIN32) || defined(_WIN64)) && !defined(__MINGW32__) >>> >>> used to conditionally declare SHA_LONG64 and U64 macros. >>> Unfortunately, this causes OpenSSL to be unusable on Cygwin because, >>> obviously, __MINGW32__ is not declared. >>> A fix could be made by appending "&& !defined(__CYGWIN__)" but in my >>> opinion >>> it is better to replace the last test with "&& defined(_MSC_VER)" because >>> things like "__int64" and "UI64" are not standard extensions and they >>> should >>> be >>> supported only if we are targetting to Microsoft VisualC++. >>> >>> Without this thing fixed, I was not able to make it working... for example, >>> if >>> you run an autoconf script that it checks the presence of openssl.h, you >>> will >>> get a message like "found but cannot be used. Missing pre-requisites?" >>> >>> Attached patch fixes this defect. >> >> Dunno what your problem exactly is, but openssl-1.0.1e is part of the >> official Cygwin distro at cygwin.com. Lots of packages in the distro >> are built against OpenSSL. >> >> The problem you have here looks self-induced. Neither _WIN32 nor _WIN64 >> are defined by default when building on Cygwin. _WIN32 is not defined >> either when including <windows.h>, at least not if you use the current >> w32api headers of the mingw64 project. _WIN64 is only defined when >> including <windows.h> and building for the 64 bit version of Cygwin, >> which isn't released yet. >> >> So, bottom line is, I don't think that your patch is necessary. You >> should rather make sure that _WIN32 isn't defined accidentally in your >> scenario. >> >> >> Corinna >> > > Hello, sorry if I have not replied... I was expecting some changes in > the bug tracker instead of in the mailing list, my mistake.
Well, it's not inappropriate to expect reply through RT, but it takes discipline to reply explicitly to [email protected] instead of openssl-dev. > Actually, in my opinion the bug is real: I believe you can't rely > just on _WIN32 and on _WIN64 macro because, as you said, it is enough > to include windows.h in the checked headers or to add -D_WIN32 to > CFLAGS to fail autoconf, which may be required by other packages. As Corinna implied it's inappropriate to define _WIN32 (or include windows.h) when compiling code with Cygwin compiler. So the key question is why do you insist on passing -D_WIN32? And correct solution should be to abstain from doing so. > Alternatively, if you prefer, the patch could also be changed as: > > #if (defined(_WIN32) || defined(_WIN64)) && !defined(__GNUC__) > > because you simply can't use the following lines in a different > environment than VisualC++ Not true. There are non-Microsoft compilers that [legitimately] pre-define _WIN32 but don't have long long, e.g. Borland. Of course one can argue that nobody is using it by now, but at least that's the original reason for why the condition looks they way it does. > or something that it does not mimic > exactly the compiler made by Microsoft: if <windows.h> is included, > somehow you may be able to use __int8/__int16/__int32/__int64 because > they will be provided by its inclusion, __int64 is internal type, it's not defined in windows.h. > but anyways you won't be > surely able to append UI64 to a long long type. By the way, this also > breaks openssl on MSYS, for the same reason. ??? Where do you get your compilers? MSYS compiler *is* MINGW and __MINGW32__ *is* defined by MSYS compiler. Even by mingw-w64 one. Well, they might have changed the last part, but then you can't just say "breaks on MSYS" without stating the version. Replacing !defined(__MINGW32__) with !defined(__GNUC__) might be sensible and it will be considered. *But* it doesn't change the fact that it's inappropriate to pass _WIN32 to Cygwin compiler. So that if condition will changed, it won't be for this report, but for more general reasons. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
