Re: Patches to compile CC++ 2 for Win32 with GCC using Mingw32

[David Sugar]

I like this patch.  I gather you have been able to build libxml2 and libiconv 
as well (perhaps as dll's) with the debian mingw32 tool chain?

My other thought is maybe we should have the mingw32 makefile build two 
seperate and dependent dll's (ccgnu and ccstd) the way the normal build tree 
does for posix targets.

On Thursday 08 August 2002 17:24, Federico Montesino Pouzols wrote:
>       Hi all,
>
>       I have been trying to compile cc++ 2 with GNU GCC as cross
> compiler for Win32 (using Mingw on Debian). At first, I used the
> Makefile.gcc in the win32 directory. I have found three errors while
> compiling...
>
>
> Error 1)
> ********
>
> socket.cpp:
>
> i586-mingw32msvc-c++ -c -I. -I../include -DHAVE_LIBXML
> -I/usr/i586-mingw32msvc/include/libxml -DHAVE_CONFIG_H -D_GNU_SOURCE
> -include ../win32/cc++/config.h -g -O2 -mthreads -o
> ../win32/../win32/socket.o ../src/socket.cpp
> ../src/socket.cpp: In function `SOCKET ost::dupSocket(unsigned int,
> ost::Socket::State)':
> ../src/socket.cpp:75: `ost::dupSocket(unsigned int, ost::Socket::State)'
> was declared `extern' and later `static'
> ../include/cc++/socket.h:573: previous declaration of
> `ost::dupSocket(unsigned int, ost::Socket::State)'
> make: *** [../win32/socket.o] Error 1
>
>
>       A patch for this is attached (patch-ccpp2-mingw-socket).
>
>
>
> Error 2)
> ********
>
> url.cpp:
>
> i586-mingw32msvc-c++ -c -I. -I../include -DHAVE_LIBXML
> -I/usr/i586-mingw32msvc/include/libxml -DHAVE_CONFIG_H -D_GNU_SOURCE
> -include ../win32/cc++/config.h -g -O2 -mthreads -o
> ../win32/../win32/url.o ../src/url.cpp
> In file included from ../src/url.cpp:43:
> ../include/cc++/url.h: In method `int ost::URLStream::aRead(char *,
> unsigned int, long unsigned int)':
> ../include/cc++/url.h:147: implicit declaration of function `int
> ost::read(...)'../include/cc++/url.h: In method `int
> ost::URLStream::aWrite(char *, unsigned int, long unsigned int)':
> ../include/cc++/url.h:150: implicit declaration of function `int
> ost::write(...)'
> make: *** [../win32/url.o] Error 1
>
>
>       A patch for this is attached (patch-ccpp2-mingw-url).
>
>
> Error 3)
> ********
>
> then, linking:
>
> port.o: En la función `ost::SocketService::run(void)':
> /home/fedemp/gnu/pristine-subversions/commoncpp2/win32/../src/port.cpp:708:
> referencia a address@hidden' sin definir
> /home/fedemp/gnu/pristine-subversions/commoncpp2/win32/../src/port.cpp:762:
> referencia a address@hidden' sin definir
> i586-mingw32msvc-dllwrap: i586-mingw32msvc-c++ terminó con estado 1
> make: *** [ccgnu2.dll] Error 1
>
>
>       Which can be solved linking ws2_32 (an updated Makefile.gcc is
> attached).
>
>       With this, a static library and a dll for Win32 can be build
> with a GNU environment.
>
>
>       There is a second way to get it. There is a free awk script
> (dsw2mak.awk) at
> http://mefriss1.swan.ac.uk/~jfonseca/gnu-win32/software/msds/index.html,
> by José Fonseca, that given a MSVC .dsp produces a makefile for
> mingw32. This has the advantage that the mingw makefile can be
> automatically updated from the new .dsps.
>
>       I have got a CCXX.mak from the current CCXX.dsp and tweaked it
> a bit so that CCXX.dll can be built (only uppercase/lowercase in the
> first letter of some names of files). It is attached.
>
>
>       There is also a third way to get it... building the library
> with the GNU GCC and autotools environment using the cross compiler
> based on Mingw32 (a typical configure and make). This method fails
> with cc++ 2. I have tested the same cross compiler environment with
> other libraries and apps and it works smoothly. However, with cc++ the
> top level makefile does not recurse into the src directory and the
> Makefile in src seems not to work. Grepping into the autoconf macros
> it seems that some work has been done to detect Mingw32 environments,
> and in fact it is correctly detected by configure.
>
>       It does not work however. It seems that some autoconf macro
> does not work well in this environment. Has anyone tested a
> configuration like this or has any clue?