Compiling and installing GNUstep on a WinXP SP2 machine works pretty
well, command line tools compile and run without problems.
In the past applications have built and at least run. On the most
recent (CVS head) version, my app dies attempting to load the bundle:
2005-07-07 09:15:25.000 AppComms.exe[3900] Disallowed time zone name
`W. Australia Standard Time'.
2005-07-07 09:15:25.000 AppComms.exe[3900] Using time zone with
absolute offset 0.
2005-07-07 09:15:25.000 AppComms.exe[3900] NSApplication.m:217
Assertion failed in initialize_gnustep_backend. Can't load object
file from backend at path c:/GNUstep/System/Library/Bundles/
libgnustep-back.bundle
Error (objc-load):126
c:\msys\1.0\home\leigh\Sources\FTDITest\ThummerComms.app
\ThummerComms.exe: Uncaught exception
NSInternalInconsistencyException, reason: NSApplication.m:217
Assertion failed in initialize_gnustep_backend. Can't load object
file from backend at path c:/GNUstep/System/Library/Bundles/
libgnustep-back.bundle
The bundle is indeed at this location.
Tracing further, the problem is in NSString -fileSystemRepresentation
which calls NSFileManager -fileSystemRepresentationWithPath: which is
returning the string prior to ":", therefore "c:/GNUstep/System/
Library/Bundles/libgnustep-back.bundle" returns "c".
NSFileManager -fileSystemRepresentationWithPath: uses NSString
cStringUsingEncoding: NSUnicodeStringEncoding if the class is
compiled with __MINGW__.
What is the current policy? Should NSApplication
initialize_gnustep_backend() be attempting to load "c:/GNUstep"
rather than "/c/GNUstep", or should cStringUsingEncoding: properly
handle DOS drive separators? I would think the latter, but I'm not
clear on what the policy of managing DOS pathnames is within the
GNUstep community?
--
Leigh M. Smith
[EMAIL PROTECTED]
http://www.leighsmith.com
_______________________________________________
Gnustep-dev mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/gnustep-dev
