On 2005-07-13 07:06:22 +0100 Lloyd Dupont <[EMAIL PROTECTED]> wrote:
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?
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).
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
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.
_______________________________________________
Discuss-gnustep mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/discuss-gnustep
