Re: glib 2.3.3 and Windows

["J. Ali Harlow" <ali juiblex co uk>]

On 2004.02.25 23:56 Hans Breuer wrote:
> At 00:14 25.02.04, J. Ali Harlow wrote:
> > I've just tried to build glib 2.3.3 under my linux-x-mingw32 build 
> > environment (thanks for the release, Owen). After Tor's comment on bug 
> > 134813 it wasn't a great surprise that it fell over badly.
>
> Just looked at the bug number and found nothing relevant (your typo or 
> mine ;-) and commited stuff laying around on my disk since the weekend. 
> Compiling dindn't fail that badly and should work at least with msvc 
> again ...

Since I see you've added a comment on the bug, I suspect typos aren't the
problem. I was referring to Tor's comment:

# > What makes you believe that glib 2.4.0 won't be useable under Windows?
#
# Oh, it was just a wild guess, based on my impression that some API
# has been added recently, but the corresponding entries haven't been
# added to the .def files for instance. And the g_child_watch stuff
# hasn't been implemented yet for Windows, and the current source in
# fact contains for instance calls waitpid() and uses SIGCHLD without
# any ifdefs.

> > My situation is that I have chosen to base the latest application I'm 
> > writing on glib 2.3.2 on the basis that 2.4.0 would be released in 
> > plenty of time before I was ready to release my own stable version. 
> > This now seems in jeopardy.
>
> Are you about to release your version very soon, do you think some small
> build glitches are jeopardy - or did I miss some breakage ?

I attached my win32 implementation of g_child_watch to bug 50296, which
seemed a sensible place since that was the origin of Matthias's changes.

I think my implementation is much better than yours :-)

Specifically it doesn't get confused if the child exits with code 259
(STILL_ACTIVE) and it doesn't need yet another thread. There aren't
many cases where it's actually easier to do something under win32 than
UNIX, but we might as well take advantage of the few that do exist.

I also opened bug 135386 and attached a fix to add the missing exports
to glib.def. I see you've added at least some of these, so this can
probably be closed.

> > Given this, I would like to look at solving these problems if noone 
> > else more qualified is available to look at these issues this week.
>
> I'm certainly not qualified for configure magic, but ...
>
> > I attach what I have so far - a patch to glibconfig.h to at least allow 
> > the build to progress to gmain.c (I don't know if including windows.h 
> > from glibconfig.h is a good idea yet, so I haven't yet submitted this 
> > to bugzilla).
>
> ... including windows.h in glibconfig.h would cause huge breakage in 
> application code due to massive namespace clashes (at least in Dia).

Yes, I can't say I'm completely surprised. I see you've just used int
under msc, which I'd be happy with but Tor seemed to be trying to avoid
this (apparantly because handles won't fit into ints under win64).

Personally I advocate making GPid hold ProcessIDs anyway for reasons I
go into in my comments to 50296. I'd appreciate your views.

Cheers,

--
J. Ali Harlow
ali juiblex co uk