[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libdispatch-gnustep/libdispatchgs-etoilé vs libdispatch0
From: |
Niels Grewe |
Subject: |
Re: libdispatch-gnustep/libdispatchgs-etoilé vs libdispatch0 |
Date: |
Mon, 1 Feb 2016 11:56:36 +0000 |
> Am 01.02.2016 um 12:39 schrieb David Chisnall <theraven@sucs.org>:
>
> On 31 Jan 2016, at 23:52, Gregory Casamento <greg.casamento@gmail.com> wrote:
>>
>> Indeed. Niels is correct. I thought at one point libdispatch was working
>> without the need for a modified libBlocksRuntime, but after some testing it
>> appears I'm incorrect.
>
> It will sometimes work. It depends on which implementation of _Block_copy
> and friends the runtime linker decides to pick. If it picks the one in
> libobjc2, everything is fine. Otherwise, it is broken.
>
> I thought that we’d modified libBlocksRuntime on FreeBSD to use weak symbols
> for various things, but it looks as if we didn’t and are just lucky with the
> link order...
I actually made multiple attempts to get fixes for this problem upstreamed. I
first tried getting things fixed directly in libdispatch, but got no response.
Then I was in contact with the maintainer of the libBlocksRuntime Debian
package to get the weak symbols solution in place. He agreed to it, but never
followed through. So after repeated poking I finally gave up. Of course, if
somebody else wants to try their patience on this, I’d be forever grateful…
Cheers,
Niels