the problem seems related to GNUSTEP_SYSTEM_ROOT being /c/GNUstep/System
(which doesn't exist according to the FileManager)
and although I deleted GNUstep.conf and updated the environment variable
to be C:/GNUstep/System.
it still ignored and still return /c/GNUstep/System from
NSPathUtilies.m:386 - GNUstepConfig
----- Original Message -----
From: "Lloyd Dupont" <lloyd@nova-mind.com>
To: "Richard Frith-Macdonald" <richard@brainstorm.co.uk>
Cc: "GNUstep Discussion" <discuss-gnustep@gnu.org>
Sent: Thursday, December 01, 2005 12:18 PM
Subject: [BUG Investigation]: New revelations!
As bug goes it becames increasingly obvious I had to hack GNUstep's
source....
when I call [NSApplication sharedApplication]; I get
====
Uncaught exception NSInternalInconsistencyException, reason:
NSApplication.m:271 Assertion failed in initialize_gnustep_backend.
Unable to find backend back
====
At line 271 the bug mean path (to bundle/framework) is null.
This path is build from gnustep_backend_framework &
gnustep_backend_bundle
which both relies on gnustep_backend_path
With the power of printf debug I discovered that gnustep_backend_path was
called 3 times with
Frameworks\GNUstep_back.framework
Bundles\libgnustep-back-010.bundle
Bundles\libgnustep-back.bundle
And that [NSStandardLibraryPaths() objectEnumerator] gives me just one
path:
C:/GNUstep/Library
The problem is my clean install / build installed the backend in:
C:\GNUstep\System\Library\Bundles\libgnustep-back-010.bundle
So I should have looked into C:\GNUstep\System\Library as well.
Now I'm going to try to understand why NSPathUtilites.m:1329
NSStandardLibraryPaths() =>
NSSearchPathForDirectoriesInDomains(NSAllApplicationsDirectory,
NSAllDomainsMask, YES);
return only "C:/GNUstep/Library" and not "C:\GNUstep\System\Library" as
well....
but that's the root of the bug....
_______________________________________________
Discuss-gnustep mailing list
Discuss-gnustep@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnustep