On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce
<digitalmars-d-announce@puremagic.com> wrote:
> On Sunday, 24 September 2017 at 09:27:42 UTC, Iain Buclaw wrote:
>> That would almost certainly only happen if you were using a different
>> druntime.  Check where your import modules are coming from, they probably
>> aren't gdc's.
> Ah yes. Thanks a lot for the hint. I tried to compile with "-v" and got:
> import    object        (/usr/include/d/object.d)
> import    core.stdc.stdarg      (/usr/include/d/core/stdc/stdarg.d)
> import    core.stdc.stdlib      (/usr/include/d/core/stdc/stdlib.d)
> import    core.stdc.config      (/usr/include/d/core/stdc/config.d)
> import    core.stdc.stddef      (/usr/include/d/core/stdc/stddef.d)
> semantic  test
> entry     main          test.d
> import    __entrypoint
> (/usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/__entrypoint.di)
> "/usr/include/d/core" is the druntime of dmd. gdc's one is in:
> /usr/lib64/gcc/x86_64-slackware-linux/5.3.0/include/d/core
> But GCC wants to use "/usr/include/d/" for some reason. If I remove dmd,
> then the example above compiles.
> I wasn't able to find how to change it. I'll probably change the runtime and
> phobos paths for dmd and move gcc's D directories into their old place.

It might be a configure flag to change that.  Though I think at least
Archlinux just applies local patches to all compilers to point the
system directory explicitly to different locations.  I'd say it's a
dmd package bug for putting dmd sources in /usr/include/d, when this
should be reserved for more general D application libraries.

Reply via email to