[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


From: Lloyd Dupont
Subject: Re: BTW
Date: Thu, 14 Jul 2005 10:00:55 +1000

I could see there is an update of the libraries (base is now 1.10.3 & GUI is now 0.9.5) but the windows installer hasen't been updated.

what could I do about that?

I don't know ... perhaps contact the people who provided the installer directly. Perhaps you could update the installer and provide a newer version?
uh... I have no idea how the installer is made...

Tomorrow I might try the following: download the sources, update my installation compiled from source, (try to update to latest GCC as well), recompile. would it be ok?

Well ... I don't know about the 'latest' GCC ... but if you use the latest GNUstep code from CVS, and follow the instructions for MinGW in the GNUstep-make package exactly (ie use the same versions of mingw,msys,gcc,libraries), you should end up with a working system. I know Nicola has done that in the last couple of days, and I updated from CVS not long ago and ended up with a working system, so those instructions work (at least on windows-xp).

uh... some reading on the web made me warry about grabbing the latest CVS stuff. for example a web reviewer was commenting about the (past?) instability of some GNUstep code and Adam Fedor replyed, "of course, he uses CVS instead of the released packages",
so you see....
Beside I've tryed in some remote time (back in... 2001/2? when I was still interested in home C coding)
to do just that (exactly follow instruction for MinGW): unsuccesffully.....

I would recommend getting a working version using that procedure before trying to vary anything by using different versions of tools and libraries.

In case no one knows I'll keep you informed....

BTW reading the website to try to find what has changed: I stumbled many times on this uninformative cryptive description: "Minor bugfixe from MingW report."

How is the 'minority' determined?

I don't know of many such descriptions ... but I would imagine it's a personal judgement, and usually means that the code change is small/obvious if you look at it. Of course, if it happens to fix a persistent crash in your particualr application, it might not be minor for you.

For example I'm sure there is some memory corruption with 1.10.1 (leading to regular random crash), could these 'minor' bugfixes, repair my application's crashes?

Maybe ... you need to look at the changes to find out. Simpler, if there are a *lot* of changes you are interested in, might be just to update to latest CVS version and try it.
Where do you think this memory corruption is?  I think the base library is

I have not clearly pointed it out yet.
The fact is: in some circumstances, just calling 'LoadLibrary("gnustep-base.dll")'
will crash the process. so it's hard to diagnose.
But yesterday I found a crash (SEGFAULT, in a pointer spaghetti code) deep NSLayoutManager
(for code working fine on MacOSX)
and another, sometimes crash, for a NSFont object coming out of an NSAttributedString attribute's
The NSLayoutManager I manage to work around it (as I don't use GNUstep, but for my application data), but the NSFont problem I have to fix (as NSAttributedString are part of my data objects).

very good at not corrupting memory on gnu/linux as I have a lot of preograms which use the base library and which I fairly frequently run under valgrind. The gui and backend libraries are less well tested, but still pretty good. That being said, there are variations for running under windows, so there could be system specific memory corruption issues, and I know of no good free tool like valgrind for windows which would let us find them. I believe that the commercial product 'purify' is comparable to valgrind, but as I'm not a windows programmer (I just use it occasionally to fix/test gnustep-base issues on mingw), I'm not likely to pay for a copy.

(and why not update the windows installer when the only changes where windows related?)

That makes me think, recently there was a discussion about the importance of the Windows port. Unfortunately I see no one seems to be interested in doing it .... :-( (well all motivated, geek kind of Windows developpers, are doing ..NET at the moment, that might be the reason...)

Guess so. As far as I know, none of the core GNUstep developers use windows at all ... apart from booting it up occasionally in order to port gnustep as a good-will gesture to the windows users out there. That's really why the windows port goes so slowly ... it's largely powered by people who don't use (and don't want to use) windows. I think we would all like the windows stuff to improve, and are all eager to help windows developers in improving it ... but we do need those windows developers.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]