Re: libobjc2 still failing tests

[Andreas Fink]

The standard linker from debian. I guess the one which comes when you install 
build-essential
I had played with using the llvm linker at some point but had other issues 

# ld -v
GNU ld (GNU Binutils for Debian) 2.28



> On 26 Jan 2019, at 13:18, David Chisnall <gnustep@theravensnest.org> wrote:
> 
> On 26 Jan 2019, at 11:57, Andreas Fink <afink@list.fink.org> wrote:
>> 
>> * thread #1, name = 'basictypes', stop reason = signal SIGSEGV: invalid 
>> address (fault address: 0x7fffff7feffc)
>> * frame #0: 0x00007ffff6a22d4e libc.so.6`_IO_vfprintf + 30
>>   frame #1: 0x00007ffff6a4be89 libc.so.6`vsnprintf + 121
>>   frame #2: 0x00007ffff6a2b2c2 libc.so.6`snprintf + 130
>>   frame #3: 0x00007ffff79060f4 libgnustep-base.so.1.26`-[NSMethodSignature 
>> _initWithObjCTypes:](self=0x000000000150d8f8, _cmd=<unavailable>, 
>> t=<unavailable>) at NSMethodSignature.m:539:4
>>   frame #4: 0x00007ffff7906241 libgnustep-base.so.1.26`+[NSMethodSignature 
>> signatureWithObjCTypes:](self=<unavailable>, _cmd=<unavailable>, 
>> t=<unavailable>) at NSMethodSignature.m:559:10
>>   frame #5: 0x00007ffff79a7d4a 
>> libgnustep-base.so.1.26`gs_objc_msg_forward2(receiver=0x00007ffff7d864f8, 
>> sel="\xffffff90\n") at GSFFIInvocation.m:140:13
>>   frame #6: 0x00007ffff72ae2c1 libobjc.so.4.6`slowMsgLookup at 
>> sendmsg2.c:149:28
> 
> I’ve seen this before.  What linker are you using?
> 
> When I saw this, it was because of a bug in old BFD ld's handling of ld -r 
> when linking the Base Additions library, which caused it to delete the 
> category that contained the lockAt: method.  This then caused infinite 
> recursion in NSObject’s initialisation.  Both lld and gold appear to work 
> fine (though lld doesn’t work for SOPE, for reasons I’ve not yet been able to 
> track down).
> 
> David
>