[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: runtime 2.0 issues. (Success!)
From: |
Andreas Fink |
Subject: |
Re: runtime 2.0 issues. (Success!) |
Date: |
Wed, 6 Mar 2019 18:01:25 +0100 |
Thanks David,
I finally managed to get a proper compiled version under Debian 9 again. This
was bugging me now for more than a month and I finally can check if I still see
these memory leaks which I saw with libobjc2-1.8
Using clang-8, a patch to gnustep-make, some environment magic to take the
right linker and compiler (not too new and not too old) finally did the trick!
There where multiple issues which reciprocally where affecting each other which
meant whatever you tried, had to fail.
I will verify this now tomorrow on a freshly installed Debian again to be sure
all is properly working and write down a nice documentation for others so they
don't have to go through these pains.
I will also will build packages for it so installing gnustep-base (and gui for
those who need it) will become a piece of cake.
> On 6 Mar 2019, at 17:15, David Chisnall <gnustep@theravensnest.org> wrote:
>
> On 06/03/2019 01:29, Andreas Fink wrote:
>> 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:
>
> This looks like the issue that I already told you about with BFD ld failing
> to correctly link -base Additions. Did you link -base with Gold or LLD
> (which work) or BFD ld (which doesn't)?
>
> David