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

[Stefan Ondrejicka <ondrej idata sk>]

On 6 Feb 2001, Owen Taylor wrote:

Hello Owen,

> > I have bit corrected the patch I sent you yesterday. There was quite
> > broken compilation of gobject library. Now it works properly. The attached
> > diff is made again glib cvs chackout from janury 29. I will appreciate any
> > commenets.
> 
> > +This file expain a bit way how to compile glib package on cygwin for
> > +use *with* cygwin POSIX runtime.
> > +  As the libtool package is not able build without problems DLLs on
> > +win32 there is need for compilation method which differ a bit from
> > +standard compilation on UNIX platforms.
> 
> 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.

> Instead of continuing to creating yet more hand-built Makefiles (and I
> suspect that Tor finds two sets already a big pain to keep up to
> date), I think I'd rather have users on Cygwin to re-libtoolize with a
> CVS snapshot until we can update the libtool shipped with libtool to a
> version with this feature.

I agree with you. It will be much easier when libtool will work
proberly. I will check that.

> We really need features from newer libtool for BeOS and AIX anyways,
> and it would even be conceivably possible to switch GLib/GTK+-1.3.x
> to CVS libtool.

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. I am not sure wheter this is posible to achive with libtool
(I am not expert on libtool, so maybe I am wrong).


> > diff -ruN glib-cvs29012001/cygglib.def glib/cygglib.def
> > --- glib-cvs29012001/cygglib.def	Thu Jan  1 01:00:00 1970
> > +++ glib/cygglib.def	Mon Feb  5 13:33:46 2001
> 
> Errr, why does cygwin need a separate defs file? (Tor can _definitely_
> tell you that maintaining the ones we have already is a pain.)

Why ? Becase some symbols already exported by native win32 are not
neccessary for cygwin. I think it was the functins for dealing with 
directories and the win32 io chanel functions (on cygwin are used
standart unix io chanel functions). I know that it is painfull to maintain
the .def files ...

> Can we either;
> 
>  - Just use that
>  - Generate the cygwin defs files from that by some sort sed script.

I think this is clever idea. Will do that ...

> > diff -ruN glib-cvs29012001/gconvert.c glib/gconvert.c
> > --- glib-cvs29012001/gconvert.c	Mon Jan 29 11:24:13 2001
> > +++ glib/gconvert.c	Sun Feb  4 21:20:46 2001
> > @@ -28,7 +28,7 @@
> >  #include "glib.h"
> >  #include "config.h"
> >  
> > -#ifdef G_OS_WIN32
> > +#if defined(G_OS_WIN32) || defined(G_WITH_CYGWIN)
> 
> OK, this is a problem that you have this all over the place. The reason
> that G_OS_WIN32 is _not_ defined for cygwin was that it was considered
> that CYGWIN should be G_OS_UNIX + G_WITH_CYGWIN since it would be
> more like Unix than like Win32. 
> 
> There are two things we can do:
> 
>  1) We could define G_OS_WIN32 for cygwin; this would be a good idea
>     only if that didn't produce a lot of:
>    
>      #if defined (G_OS_WIN32) || defined (G_WITH_CYGWIN)

Rather not, because it will force on other places to do 

  #if defined (G_OS_WIN32) || !defined (G_WITH_CYGWIN)

>  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.

> > diff -ruN glib-cvs29012001/gfileutils.c glib/gfileutils.c
> > --- glib-cvs29012001/gfileutils.c	Mon Jan 29 11:24:14 2001
> > +++ glib/gfileutils.c	Sun Feb  4 21:20:46 2001
> > @@ -378,7 +378,7 @@
> >    struct stat stat_buf;
> >    gint fd;
> >    
> > -  fd = open (filename, O_RDONLY);
> > +  fd = open (filename, O_RDONLY | O_BINARY);
> 
> Sigh. Having read() do line-end translation is one of the most 
> screwed up things....

:-) you are so right ... O_BINARY is not problem with cygwin while you are
on the cygwin virtualy mounted directories in binary mode, but once you go
outside this mounted directories, you are in troubles :-(

> Maybe we should define a G_O_BINARY, since O_BINARY isn't portable.
> (Though this file has #define, this comes up over and over again :-()

Yes you are right. The gfileutils.c contains

#ifndef O_BINARY
#define O_BINARY 0
#endif

That's why I dare to put that in non WIN32 specific code. I don't think
that it is necessary de define G_O_BINARY, because it will be only
convenience define, and programmers who will want to write portable code
to win32 (I don't know about any other platfom which need to use O_BINARY
to read binary files) will nedd to use explicitly the G_O_BINARY in his
code. Maybe better idea will be to define the io functions in in glib and
force g_open explicitly with O_BINARY. But probably you will not agree
with this.

Best regards,
Stevo.

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