[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
fileSystemRepresentationWithPath:
From: |
Leigh Smith |
Subject: |
fileSystemRepresentationWithPath: |
Date: |
Fri, 8 Jul 2005 19:02:45 +0800 |
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.
I'm dubious about that ... there is a space in the path after the
'.app' ... which is probably incorrect. Perhaps that's the cause
of your trouble? Also, there is a space in 'c:/GNUstep/System/
Library/Bundles/ libgnustep-back.bundle'
Any idea where the spaces come from?
I rechecked the error message and the space seems to have been
inserted by my mail client.
I'm not sure what you mean by that ... it should definitely not do
anything special with DOS drive separators. All that method does
is provide a pointer to a region of memory containing a
representation of the string in the specified character encoding.
Digging deeper, the problem reduces to that NSFileManager -
fileSystemRepresentationWithPath: is defined to return a unicode
encoded const char * string, whereas NSBundle -load NSDebugFLLog()
statements are assuming the string returned from
fileSystemRepresentationWithPath: is an 8 bit char *, not unicode.
The __objc_dynamic_link() definition in win32-load.h calls
LoadLibraryExW() which assumes (casts) it's filename parameter is
unichar *.
The problem seems to be that the string returned by
fileSystemRepresentationWithPath: does not have the leading '\0' for
latin unicode, but subsequent characters do have the leading '\0'
hence the 'c' alone being displayed by the NSBundle debugging code
(which prints using %s).
I'm almost certain there should be a leading '\0' in the unicode
string returned by fileSystemRepresentationWithPath:?
NSString -dataUsingEncoding:allowLossyConversion: has the following
code:
else if (encoding == NSUnicodeStringEncoding)
{
unichar *buff;
buff = (unichar*)NSZoneMalloc(NSDefaultMallocZone(),
sizeof(unichar)*(len+1));
buff[0] = byteOrderMark;
[self getCharacters: &buff[1] range: ((NSRange){0, len})];
return [NSDataClass dataWithBytesNoCopy: buff
length: sizeof(unichar)*(len+1)];
}
Adding
if (objc_load_module([object fileSystemRepresentation],
stderr, _bundle_load_callback, NULL, NULL))
{
const char *fsrp = [object fileSystemRepresentation];
NSLog(@"LMS Couldn't load module %0x, %0x, %0x, %0x\n", fsrp[0], fsrp
[1], fsrp[2], fsrp[3]);
_codeLoaded = NO;
DESTROY(_loadingFrameworks);
DESTROY(_currentFrameworkName);
[load_lock unlock];
return NO;
}
to NSBundle -load when run with:
openapp ThummerComms.app --GNU-Debug=NSBundle
produces:
2005-07-08 10:51:56.000 ThummerComms.exe[528] Disallowed time zone
name `W. Australia Standard Time'.
2005-07-08 10:51:56.000 ThummerComms.exe[528] Using time zone with
absolute offset 0.
2005-07-08 10:51:56.000 ThummerComms.exe[528] File NSBundle.m: 823.
In [NSBundle +mainBundle] Found main in c:/msys/1.0/home/leigh/
Sources/FTDITest/ThummerComms.app
2005-07-08 10:51:56.000 ThummerComms.exe[528] LMS self executablePath
result = c:/GNUstep/System/Library/Bundles/libgnustep-back.bundle/./
libgnustep-back.dll
2005-07-08 10:51:56.000 ThummerComms.exe[528] File objc-load.m: 110.
In objc_initialize_loading Debug (objc-load): initializing dynamic
loader for c
2005-07-08 10:51:56.000 ThummerComms.exe[528] File objc-load.m: 174.
In objc_load_module Debug (objc-load): Linking file c
2005-07-08 10:51:56.000 ThummerComms.exe[528] LMS Couldn't load
module 63, 0, 3a, 0
2005-07-08 10:51:56.000 ThummerComms.exe[528] 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
My point being the lack of byteOrderMark, or a leading '\0' in the
string, unless there is strange behaviour treating unichar * strings
and casting them back to char *.
I'll dig in further.
I would think the latter, but I'm not clear on what the policy of
managing DOS pathnames is within the GNUstep community?
This has changed ... current policy is to handle paths in either
unix or windows format internally, and to expect the interface to
the outside world to use native format paths (ie not to perform
translations).
Ok, thanks for the clarification.
--
Leigh M. Smith
address@hidden
http://www.leighsmith.com
- fileSystemRepresentationWithPath:,
Leigh Smith <=