bug-commoncpp
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: David Sugar
Subject: Re: Patches to compile CC++ 2 for Win32 with GCC using Mingw32
Date: Thu, 8 Aug 2002 18:25:27 -0400
User-agent: KMail/1.4.1

This is very interesting.  I had wanted to be able to have people build Common 
C++ win32 target dll's out of mingw32 hosted on a GNU/Linux system like this 
for awhile.  I will have to look at getting these patches in.

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?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]