gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Still getting the following failure...


From: Gregory Casamento
Subject: Re: Still getting the following failure...
Date: Fri, 19 Jul 2013 16:02:43 -0400

As an aside with respect to clang...

Clang has been very stable lately and it's been my primary compiler for the past serveral months.   I recommend more of us give it a try and use it on a regular basis.  Clang has several advantages over gcc which are obvious:

1) Apple is involved in its development (while not an advantage in and of itself, it does mean that the compiler will be actively maintained) 
2) clang is faster than gcc
3) supports more Objective-C features than gcc does... while some may say that they don't need this feature or that feature and, indeed, might be satisfied with the likes of gcc 2.95, many developers coming out of college are used to these features and will expect them in a reasonably modern implementation of ObjC.  
4) Also, The Objective-C language is the main reason for clang's existence while with gcc it is a second class citizen and is not considered release critical.
5) it is modular and written in C++ so parts of it can be reused easily... this would have been good back when I wrote the ObjC header parser since I wouldn't have had to have wasted time writing a recursive descent parser to gather information from the header.

There are more advantages I'm sure, but the above are the main reasons why it's become important to me.   GCC has several critical problems, not the least of which is it's monolithic design and it's community's tendency towards favoring C and C++ to the detriment of all other languages supported by it.

Later, Greg




On Fri, Jul 19, 2013 at 3:22 PM, Richard Frith-Macdonald <address@hidden> wrote:

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.

Perhaps nobody is responding because it's not a problem anybody has seen (I haven't).
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



--
Gregory Casamento
Open Logic Corporation, Principal Consultant
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell)
http://www.gnustep.org
http://heronsperch.blogspot.com

reply via email to

[Prev in Thread] Current Thread [Next in Thread]