Re: runtime 2.0 issues.

[Andreas Fink]

I just retried with clang-8 compiled from source.

Indeed this problem in ./configure of gnustep-base went away.

However all tests still fail.

its compiled this way during the test:

clang  -Wl,-rpath,/Users/afink/development/gnustep2/base/Source/./obj -rdynamic 
-rdynamic -rdynamic  -rdynamic -pthread  -fexceptions 
-fobjc-runtime=gnustep-2.0 -fblocks -o obj/basictypes  
./obj/basictypes.obj/basictypes.m.o 
-L/Users/afink/development/gnustep2/base/Source/./obj 
-L/root/GNUstep/Library/Libraries -L/usr/local/lib -lgnustep-base -lpthread 
-lobjc -lm


this produces a binary without an error but when running the binary, you simply 
get a segfault. and thats the case for all binaries created in the test.

Running it in lldb shows that it throws an exception which then while in the 
exception, it creates an exception which then creates a recursive infinite loop 
until the stack is filled up.
Its caused by this:

#57168 0x000000000040b332 in main () at basictypes.m:161
161       NSAutoreleasePool *pool = [NSAutoreleasePool new];
(gdb) down
#57167 0x00007ffff72b17c4 in objc_msgSend_fpret () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57166 0x00007ffff72ad3c7 in slowMsgLookup () from /usr/local/lib/libobjc.so.4.6
(gdb) down
#57165 0x00007ffff72a41c5 in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57164 0x00007ffff72a438e in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57163 0x00007ffff7913590 in +[NSObject initialize] (self=0x7ffff7d79b08 
<._OBJC_CLASS_NSObject>, _cmd=<optimized out>) at NSObject.m:1091
1091          NSConstantStringClass = [NSString constantStringClass];
(gdb) down
#57162 0x00007ffff72b17c4 in objc_msgSend_fpret () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57161 0x00007ffff72ad3c7 in slowMsgLookup () from /usr/local/lib/libobjc.so.4.6
(gdb) down
#57160 0x00007ffff72a438e in objc_send_initialize () from 
/usr/local/lib/libobjc.so.4.6
(gdb) down
#57159 0x00007ffff795372b in +[NSString initialize] (self=0x7ffff7d864f8 
<._OBJC_CLASS_NSString>, _cmd=<optimized out>) at NSString.m:827
827           nonBase = [NSCharacterSet nonBaseCharacterSet];

So where back in libobjc2 code 

> On 6 Mar 2019, at 01:27, David Chisnall <gnustep@theravensnest.org> wrote:
> 
> On 05/03/2019 12:45, Andreas Fink wrote:
> 
>> Making all for tool cvtenc...
>>  Linking tool cvtenc ...
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x18): undefined 
>> reference to `__start___objc_classes'
>> ./obj/cvtenc.obj/cvtenc.m.o:(.data..objc_init[.objc_init]+0x20): undefined 
>> reference to `__stop___objc_classes'
> 
> As I have said before, this is a bug in clang 7.x  It is fixed in the 8.x 
> release branch and the fix is back-ported in the FreeBSD llvm70 package.  If 
> your favourite operating system's LLVM 7 package does not work, please ask 
> them to incorporate this fix:
> 
> https://svnweb.freebsd.org/ports/head/devel/llvm70/files/clang/patch-tools_clang_lib_CodeGen_CGObjCGNU.cpp?revision=489195&view=markup
> 
> This bug doesn't affect real code, but it will be a problem for any programs 
> that use Objective-C but don't contain any classes, which unfortunately 
> includes most of the GNUstep base configure scripts.
> 
> I have tested clang 8 on FreeBSD and am able to build all of the GNUstep 
> applications that I've tried (all of the ones in the FreeBSD ports 
> collection) with it without issues.  This version already contains the bug 
> fix.  It does cause a regression in one of the libobjc2 tests, which I'm 
> working on tracking down (it's triggered by a change to how LLVM does ARC 
> optimisation, but that's not actually the cause), but that particular pattern 
> is unlikely to occur in real code.
> 
> David
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep