Re: [gtkmm] Re: [sigc] Building libsigc++ under Win32 for use with Intel C++ Compiler 6.0

[Cedric Gustin <cgustin ibelgique com>]

At 07:47 AM 11/6/2002 +0000, Dirk Gerrits wrote:

> My goal is to be able to create Windows apps using gtkmm2. I'd like to be 
> able to use Intel6 for this which is a pretty nice compiler and integrates 
> seamlessly into Visual Studio .Net.

I don't have access to the Intel compiler but last time I tried MSVC++ 
could not compile libsigc++ due to a "partial template specialization" if I 
remember correctly

> Someone replied to my gtkmm-list post privately (not sure if he wants to 
> remain anonymous) saying that the libraries should be compatible with MSVC 
> and Intel if they are compiled using -mms-bitfields with GCC/MinGW.

-mms-bitfields (the old -fnative-struct) makes the gtk+-2.0 library 
compatible between MSVC and mingw because the C compiler does not mangle 
the function names, unlike C++ (except if you use extern "C" around all 
your declarations !!!). I don't think MSVC++ and mingw share the same name 
mangling scheme.

> Anyway, at this point I'm so frustrated that settling to use MinGW for my 
> app doesn't seem like much of a problem. Besides, it's probably a lot more 
> standard compliant than Intel anyway. ;)
>
> So, armed with all the information I gathered from your helpful email and 
> some Googling, I did the following:
>
> 1) Installed MinGW-2.0.0-3 to C:\MinGW.
>
> 2) Ran Cygwin's setup.exe and made it download and install ALL available 
> packages
> from the ftp://ftp.sunsite.dk/ mirror to C:\cygwin. (I figured that this would
> give me the least dependency problems, and I've got the harddisk space. ;)
>
> 3) Edited C:\cygwin\etc\profile for MinGW:
> PATH="/cygdrive/c/MinGW/bin:/usr/local/bin:/usr/bin:/bin:$PATH"
>
> 4) Changed line 5363 of C:\cygwin\usr\autotool\devel\share\aclocal\libtool.m4
> and line 2956 of C:\cygwin\usr\autotool\stable\share\aclocal\libtool.m4 from:
> #       printf ("\t%s @ %ld ;\n", erva+name_rva, 1+ i);
> to:
> #       printf ("\t\"%s\" @ %ld ;\n", erva+name_rva, 1+ i);

I don't know if the development brach of the autotools from cygwin will 
work in our case. I personally compiled the latest stable release of those 
tools (autoconf-2.52, automake-1.6.1, libtool-1.4.2 and modified libtool.m4 
as you did.


> As described in http://bugzilla.gnome.org/show_bug.cgi?id=91033
> (Did I do this right? I thought # indicated a comment?)
>
> 5) Downloaded and unzipped all of the following files (with use folder 
> names and overwrite all)
> 5a) From http://www.gimp.org/win32:
> atk-1.0.3-20020821.zip
> atk-dev-1.0.3-20020821.zip
> glib-2.0.6-20020802.zip
> glib-2.0.6.tar.gz
> glib-dev-2.0.6-20020802.zip
> gtk+-1.3.0-20020922.zip
> gtk+-2.0.6-20020921.zip
> gtk+-dev-1.3.0-20020912.zip
> gtk+-dev-2.0.6-20020921.zip

You installed both gtk-1.2 (gtk+-1.3.0 brach) and gtk+-2.0 (gtk+-2.0.x 
branch). I don't know if they work nicely together, especially if they were 
installed in the same root directory !!! If I was you, I would install the 
gtk+-2.0.x libs only and try to compile a simple gtk+-2.0 example.

> 5b) From http://www.pcpm.ucl.ac.be/~gustin/win32_ports:
> libsigc++-1.2.1-win32.tar.gz
> gtkmm-2.0.0-win32.tar.gz
>
> (Maybe this is overkill? And perhaps I downgraded some of the cygwin 
> packages? But trying to build this stuff myself has invoked a bad case of 
> dependency-paranoia. After all this my cygwin dir is 883 MB though.)

If you install the full cygwin, you might get conflicts with cygwin 
libraries when using libtool. An example I frequently encountered is the 
libintl and iconv libraries. When possible, libtool looks for .la files. 
Because libintl and iconv do not come with those .la files (or they are 
broken). libtool reverts to the .la files from cygwin -> you get a bunch of 
undefined symbols and other errrors at link time.

Cedric