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 <[email protected]> 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 <[email protected]> wrote: >> >> On 26 Jan 2019, at 11:57, Andreas Fink <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnustep _______________________________________________ Discuss-gnustep mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnustep
