|
| From: | Gregory Casamento |
| Subject: | Re: Still getting the following failure... |
| Date: | Fri, 19 Jul 2013 15:41:40 -0400 |
Perhaps nobody is responding because it's not a problem anybody has seen (I haven't).
On 19 Jul 2013, at 19:06, Vincent R. <address@hidden> wrote:
> Le 19.07.2013 19:36, Vincent R. a écrit :
>> Le 18.07.2013 17:06, Vincent R. a écrit :
>>> Le 18.07.2013 17:00, Vincent R. a écrit :
>>>> Le 18.07.2013 04:51, Gregory Casamento a écrit :
>>>>> Creating Gorm.app/Resources/Info-gnustep.plist...
>>>>>
>>>>> plmerge: Uncaught exception (null), reason:
>>>>> -initWithBytes:lenth:encoding given nul bytes
>>>>
>>>> I have reported it in a previous message but nobody cares ...
>>>
>>> See my second message entitled : compiling GNUstep with clang, in my
>>> first message I wrote that I had some errors
>>> than I have understood I needed to compile libc++ then in my second
>>> message I had a crash inside plmerge :
>>>
>>> I am copy/pasting :
>>>
>>>
>>> if [ -r "libgnustep-back-023Info.plist" ]; then \
>>> plmerge libgnustep-back-023.bundle/Resources/Info-gnustep.plist
>>> libgnustep-back-023Info.plist; \
>>> fi
>>> plmerge: Uncaught exception (null), reason:
>>> -initWithBytes:lenth:encoding given nul bytes
>>> Aborted
>>> make[3]: ***
>>> [libgnustep-back-023.bundle/Resources/Info-gnustep.plist] Error 134
>>> make[3]: *** Deleting file
>>> `libgnustep-back-023.bundle/Resources/Info-gnustep.plist'
>>> make[2]: *** [libgnustep-back-023.all.bundle.variables] Error 2
>>> make[1]: *** [internal-all] Error 2
>>> make[1]: Leaving directory `/home/vincent/objc2cs/gnustep/core/back/Source'
>>>
>>>
>>> I tried to debug but ut's not easy because even if I have stripped
>>> libobjc2 I generally end up inside all the objc
>>> machinery, however at the end I think the problem comes from the
>>> NSString with utf8 because the last line before the crash is inside
>>> NSPathUtilities
>>>
>>> if ([c count] > 0)
>>> {
>>> /*
>>> * The dictionary should be empty ... report problems
>>> */
>>> fprintf(stderr, "Configuration contains unknown keys - %s\n",
>>> [[[c allKeys] description] UTF8String]);
>>> }
>>>
>>> The problem seems to be the UTF8String...
>>> I tried to put a breakpoint inside but it didn't work.
>>> During my first build attempt there was a message about missing local
>>> en_EN-8859 or something like that but I don't manage to get this
>>> message
>>> again so maybe it could come from that.
>>
>>
>> Actually I was wrong the problem is not inside UTF8String but before,
>> the last line I can debug is inside
>> descriptionWithLocale, then gdb doesn't manage to show me GSPropertyListMake
>>
>> - (NSString*) descriptionWithLocale: (id)locale
>> indent: (NSUInteger)level
>> {
>> NSString *result = nil;
>>
>> GSPropertyListMake(self, locale, NO, YES, level == 1 ? 3 : 2, &result);
>>
>> return result;
>> }
>>
> Instead of debugging maybe there is nothing wrong in the code but just the files doesn't exist ...
> Stopping to investigate and I wait for someone to write a very good guide about how to compile GNUstep with clang.
> I have already spent too much time on this.
I'm not a regular user of clang myself because I mostly want reliability and clang has been highly unstable, but I believe that's changed.
At least clang-3.3 and the latest libobc2 seems to be a working pretty well.
I guess someone should have asked you for more information, since the above is not remotely enough for anyone to diagnose anything unless they've seen the issue before.
Typically you'd want to start with a stacktrace, and details about compiler and library version, options chosen when configuring etc.
One thing I can suggest which might help is: check what results you got from the gnustep-base testsuite, or if you didn't bother running it, try doing so. If there are problems in your basic build, that's likely to show them up.
_______________________________________________
Gnustep-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/gnustep-dev
| [Prev in Thread] | Current Thread | [Next in Thread] |