Re: revised patch for glib compilation on cygwin with POSIX runtime
- From: Stefan Ondrejicka <ondrej idata sk>
- To: Owen Taylor <otaylor redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: revised patch for glib compilation on cygwin with POSIX runtime
- Date: Wed, 7 Feb 2001 10:23:15 +0100 (CET)
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/
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]