On 9 October 2017 at 10:03, Eugene Wissner via Digitalmars-d-announce <firstname.lastname@example.org> 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.