On Monday, 9 October 2017 at 08:10:41 UTC, Iain Buclaw wrote:
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/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.

I've chosen "/usr/include/d" for dmd since freebsd seems to use it and IIRC the debian-family aswell (I'm maintaining dmd package aswell).

I compared installation directories for c/c++ and gcc include files are in "/usr/include/c++/5.3.0/", llvm: "/usr/include/llvm". So the appropriate way would be probably just to put dmd stuff in "/usr/include/dmd".

Maybe I'll look into it later again. At least I have a quick solution for now to get both compilers work on one system.

Reply via email to