Re: Tests and issues on Win32

[Fred Kiefer]

Larry Cow wrote:
> I compiled the latest -gui and -back on the latest win32 installer. 
> Everything has gone surprisingly well, except that the need to add a few 
> libraries (libjpeg, libpng, libtiff) manually should be removed, 
> shouldn't it?

Sorry, I don't understand, what you mean by this. Would you expect the 
installer to provide all libraries GNUstep is using? Some of them may 
already be installed in a different (sometimes newer) version.

> Anyway, when trying to play with gnustep-examples, some problem arose. 
> Here is a little check-list:
>
> * NSBrowserTest.app: OK, when resizing the window, the content is only 
> refreshed once the resize is done.

Hm yes, a ptach by MA Garcias may fix this. I just never found the time 
to test it myself.


> * NSImageTest.app: 'Undefined reference to random'. How this should be 
> resolved?

We could switch to use rand(), which is more portable, GUI already uses it.

> * NSPanelTest.app:
>
> Compiles fine, but once launched, hangs forever (or at least for a 
> couple of minutes on my Athlon XP 2400).
>
> * Ink.app: Hangs.

Oops, Ink works fine with Cygwin, or at least it did the last time I 
tested. Looks like I need to boot Windows today.

> * GPuzzle.app:
>
> Compile fails with:
> GNUmakefile:6: /d/GNUstep/System/Makefiles/common.make: No such file or 
> directory
> GNUmakefile:27: /d/GNUstep/System/Makefiles/application.make: No such 
> file or directory
> make: *** No rule to make target 
> `/d/GNUstep/System/Makefiles/application.make'.  Stop.

A small glitch in the make file, Adfam already correct this.

> * GSTest.app:
>
> Compile fails with:
> Making all for bundle NSOutlineView-test...
> Compiling file NSOutlineView-test.m ...
> In file included from d:/GNUstep/System/Library/Headers/AppKit/AppKit.h:91,
>                 from NSOutlineView-test.m:27:
> d:/GNUstep/System/Library/Headers/AppKit/NSMenu.h:390: internal error: 
> Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
>
> Don't know if we should report that to mingw or not.


> Note: the detached menu behaviour is quite strange. Detached submenus 
> are detroyed as soon as you open another submenu. There is no other way 
> to close a detached submenu, so maybe this is normal. And detached 
> menus' position isn't remembered, either.

Sounds normal to me.