Re: libobjc2 still failing tests

[Andreas Fink]

I can reproduce the same problem with

export LD=/usr/bin/ld64.lld-8

libobjc compiles fine
gnustep-base compiles fine
running tests however fail miserably.

If you want access to the build system I used, contact me offline.
I'm desperately trying to build a stable recent version of libobjc2 + 
foundation so my stuff can build on top properly.
The older version I use currently seems to not release memory in some cases and 
out of a sudden my apps eat gigabytes of ram for nothing (and its not my 
objects not being deallocated. I verified this)


> On 26 Jan 2019, at 13:21, Andreas Fink <afink@list.fink.org> wrote:
> 
> 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
>> 
> 
> 
> 
> _______________________________________________
> Discuss-gnustep mailing list
> Discuss-gnustep@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnustep