dcplusplus bzr rev 2390 fails to link in release mode with mingw g++ 4.5.2 and ld 2.21

[cologic]

A reprise of my previous recent bug, but this time using http://mingw-cross-env.nongnu.org/ as suggested. The current release is only still gcc 4.5.1-based, but the development version at http://mingw-cross-env.nongnu.org/#development is 4.5.2, which was claimed to have worked. As with that bug, everything functions fine creating a debug build. In release mode, however, my results are identical to before (this time with a fresh local bzr branch):

% scons mode=release prefix=i686-pc-mingw32-
scons: Reading SConscript files ...
Checking for C++ header file htmlhelp.h... (cached) no
Checking for C++ header file natupnp.h... (cached) no
scons: done reading SConscript files.
scons: Building targets ...
Linking build/release-mingw/bin/DCPlusPlus.exe (static)
/opt/mingw/usr/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/lib/libmsvcrt.a(duyms00667.o):(.text+0x0): multiple definition of `_isxdigit'
build/release-mingw/dcpp/libdcpp.a(SimpleXMLReader.o):/opt/mingw/usr/lib/gcc/i686-pc-mingw32/4.5.2/../../../../i686-pc-mingw32/include/ctype.h:164: first defined here
collect2: ld returned 1 exit status
# collect2 4.98 3.50
scons: *** [build/release-mingw/bin/DCPlusPlus.exe] Error 1
scons: building terminated because of errors.
% i686-pc-mingw32-g++ --version
i686-pc-mingw32-g++ (GCC) 4.5.2
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

% i686-pc-mingw32-ld --version
GNU ld (GNU Binutils) 2.21
Copyright 2010 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) a later version.
This program has absolutely no warranty.

[poy (poy)]

this might be yet another mingw / mingw64 incompatibility - the latest openssl binaries in the repositories have been compiled with mingw64. then again, it works on mingw on Windows.

to verify whether this is the cause, try to replace your openssl/include and openssl/lib directories with a previous version that wasn't compiled with mingw64, for example the ones in the DC++ 0.770 source code.

[cologic (cologic)]

Replacing my openssl/lib directories with the versions from 0.770 source was enough to build successfully both debug and release versions. Replacing both openssl/lib and openssl/include in bzr using 0.770 source allows both debug and release versions to build as well.

[poy (poy)]

possible solutions:

- find out why this incompatibility occurs. i encountered some regarding time_t being 32-bit in mingw64 and 64-bit in standard mingw, and perhaps a few others; i could work around all of them by compiling openssl with the __CRT__NO_INLINE def. there may just be another such define to find here.

- build openssl with a standard mingw. i can't do that from Cygwin, as it only offers mingw64 as a cross-compiler (although mingw is supposedly "in the works"); but you can always do it by applying the patch in the openssl/build directory (takes care of some compile flags) and building openssl with:
./Configure mingw --cross-compile-prefix=i686-pc-mingw32-
make

[cologic (cologic)]

The second solution is problematic because it requires maintaining local/modified copies of the DC++ repository around so as to avoid patching and recompiling OpenSSL every time one gets a fresh bzr branch of lp:dcplusplus if using an incompatible version of MinGW. It seems suitable as a temporary fix, but not so much longer-term.

The first solution probably will require less time ultimately anyway - this mingw/mingw64 incompatibility is at times real/intrinsic, but such superficial differences as you describe create support problems which sap time. It seems like the better solution.

[cologic (cologic)]

Whilst I've used your patch.patch file and compiled BCDC++ 0.781 in release mode using this mingw version without any visible issues, I'm also wary; you're much more expert than I am about OpenSSL and it took weeks for you to narrow down some edge-case stability problems. How did you solve those and does doing what you suggested avoid those assuming I got version 1.0.0c, matching DC++ 0.781, from https://www.openssl.org/source/openssl-1.0.0c.tar.gz ?

[iceman50 (bdcdevel)]

iirc it was an issue with OpenSSL being compiled for DOS optimization but I may be wrong

[poy (poy)]

that bug has been reported and discussed at length on <http://rt.openssl.org/Ticket/Display.html?id=2381> (login: guest / guest); it led to <http://cvs.openssl.org/chngview?cn=20094> which has been released in OpenSSL 1.0.0c. therefore, using any build of OpenSSL 1.0.0c with DC++ should be safe.

still, it would be preferable if my patch were applied, as:
- it adds -g to generate debug information with the libraries.
- it defines OPENSSL_SYSNAME_WIN32, the absence of which still has a few non-critical consequences despite the above bug report. my understanding is that the openssl team whishes to keep mingw builds able to run on old Windows (98, etc).
- it defines __CRT__NO_INLINE which was only a way to ensure mingw / mingw64 compatibility.
- it removes -mno-cygwin, but my report also led to <http://cvs.openssl.org/chngview?cn=20110> which automatically removes the flag when it is not supported.

if you have a build environment with the official mingw ready, feel free to commit new libraries after applying the patch. there should be no change in header files (include/ dir), just libs.
i would do it but i am waiting for Cygwin to provide one such compiler (currently stalled - <http://cygwin.com/ml/cygwin-apps/2011-01/msg00037.html>). i could also try with an MSYS environment if it is really necessary.

[cologic (cologic)]

DC++ bzr 2413 has new libraries, using your patch.

[poy (poy)]

Fixed in DC++ 0.782.