Compiler-generated implicit symbols and --gc-sections
Joakim
joakim at airpost.net
Thu Jan 9 08:44:46 PST 2014
On Thursday, 9 January 2014 at 10:15:46 UTC, Mike wrote:
> On Thursday, 9 January 2014 at 07:51:48 UTC, Mike wrote:
>> On Tuesday, 7 January 2014 at 11:04:45 UTC, Joakim wrote:
>>> I ran into this recently when compiling for Android/x86, as
>>> the Android NDK linker calls --gc-sections by default. I was
>>> able to reproduce the segfault with dmd compiling a linux/x86
>>> executable with the --gc-sections flag added to the linker
>>> command, when compiling sieve.d from the samples. I think
>>> sieve.d was working fine when I removed the recent patches
>>> for shared library support on linux, in sections_linux.d, so
>>> this incompatibility might be related to the shared library
>>> work. I'm not sure if you're even using that work though, so
>>> maybe that's just one of the ways that gc-sections trips up.
>>
>> Interesting! I'd like to take the current 4.8 backport and
>> compile it without the shared library stuff to test this out.
>> But I don't know how. Would you mind giving me a quick
>> explanation on how to remove these patches using git? I'm
>> really quite new to some of these tools.
>
> Nevermind that last post. I thought you were talking about code
> in GDC, not the runtime. My runtime is only about 400 lines
> total, and I'm not anywhere near sections.d.
Yeah, that's in druntime, which is what I'm porting to
Android/x86. Interestingly, the segfault would go away if I
removed --gc-sections, so that alone seemed to be causing it, on
both linux/x86 and Android/x86.
More information about the D.gnu
mailing list