Re: revised patch for glib compilation on cygwin with POSIX runtime

[Stefan Ondrejicka <ondrej idata sk>]

On Thu, 8 Feb 2001, Tor Lillqvist wrote:

Hello,

> Sorry for following up so late. Haven't really had time to read my
> mail properly for many days. 

No need to be sorry. I know what are you talking about. I have many times
same problems with supporting my projects :-(

> Can I assume that you Stefan will revise the patch a bit according to
> the discussion and my comments below, and send in a re-revised one?

Yes of course, I will do, and mostly have just done yesterday. When I will
finish my attempts to get working compilation with the latest libtool I
will send new revised patch.

> About the Makefiles: Some week ago I tinkered with building makefiles
> for mingw compilation using auto* et al. It almost worked. I had to do
> some manual dos2unix conversions at various places. Certainly I think
> that for cygwin it won't be necessary to have hand-written makefiles.

With cygwin it is not necessary to do CRLF/LF conversions when you are
building packages inside virtualy mounted directories in binary mode.

After small changes to glibs configure.in the new libtool will probably
build the DLL. Now just succesfully work for me at least compilation of
separate object files for DLL and static library. For now I am not able to
get build DLL because I have only staticaly compiled libiconv and libintl
now, and libtool refuses to build DLL when all libraries on which it
depends are not DLLs. This is bit annoying ... In sunday I will have more
time to build all required DLLs and play with it bit more.

>  > > I believe that CVS versions of libtool provide support for Win32 DLLs.
> 
>  > I have checked out libtool from CVS about four months ago and was not
>  > able to get compilation of DDLs working. Maybe there has something changed
>  > during the time.
> 
> The bleeding edge is better, I think. Although I don't remember
> exactly how far I got when I hacked on it.

Yes it is. There are some bugs in the libtool script (mostly missing
quotes around some variables in test-s). And also I was not able to
bootstrap it on cygwin, but after bootstraping it on linux, the
compilation on cygwin went well ...

>  > Ok. I will be glad when this new libtool will work. Only one thing is,
>  > that I would like to keep differently named .dll libraries for cygwin
>  > (prefixed with cyg) to avoid collision with .dll libraries compiled for
>  > native Win32.
> 
> Yes, that is very important.

Yes, I agree. But after reading twice the info documentation of libtool, I
see no way to achive that without introducing separate rules intto
makefiles for building cygwin DLLs. Anyone here, who knows how to do it ?

>  > I am not sure wheter this is posible to achive with libtool
>  > (I am not expert on libtool, so maybe I am wrong).
> 
> If not currently, it should be made possible... I would think that it
> is possible, as the cyg* prefix is standard in cygwin now.

As I wrote above, currently I have not find any way to do it without
modifying the script for generating libtool. All of the libraries
compiled for cygwin I saw, use hacked makefiles to build DLLs.

>  > >  - Generate the cygwin defs files from that by some sort sed script.
> 
> A sed script that just deletes the g_win32_ entries might be suitable.

I just have simple awk script to do this. But probably when using the
standard compilation with libtool the .def files will be useless, as it
extract the export symbols with dlltool script.

>  > >  2) We could make another #define that applies to both Cygwin and Win32,
>  > >     say, G_WIN32_PLATFORM.
> 
>  > I think this can be better. I can do this if Tor agree.
> 
> Yes, I agree.

Great! I have just doen this. Maybe today I will extract the patch which
do changes to sources for cygwin and the makfiles I will try to solve
during weekend or later in separate patch ...

> About the g_win32_opendir/readdir etc functions: Any opinions whether
> they belong in GLib at all? There are already dirent emulation
> functions in libmingw32, which is linked in by default by the mingw
> gcc. Of course, this doesn't help those who use MSVC. My opinion is
> that these functions should be removed from glib, and instead the
> mingw ones moved into a library of their own, that can then be used
> also by MSVC.

I think it can remain in glib and be used only when compiling with MSVC.
And for mingw compilation can be used the routines from libmingw.

To be honest, I am not using much the native implementation of gtk+ on
win32. I am unix programmer, and I just want to be able to run my unix
programs on Win32 without much effort with porting it. And your great work 
on porting gtk+ to windows and the great cygwin allows me to do that
painlessly. Thanks!

Best regards,
Stevo.

-- 
Stefan Ondrejicka <ondrej idata sk>
Beethovenova 11, 917 08 Trnava, Slovakia
http://www.idata.sk/~ondrej/