On Thursday, 17 October 2013 at 10:58:43 UTC, Joseph Rushton Wakeling wrote:
> On 17/10/13 11:09, Johannes Pfau wrote:
>> Wait - this is a different problem. It's not a path problem,
>> it's really a .di/.d problem.
>>
>> DMD seems to ship .d include files for druntime now, they're no longer
>> shipping the .di files. The archlinux packages even do this for gdc.
>> Some stuff now depends on this, as having the source code available
>> allows more stuff to work in ctfe.
>>
>> We have to fix this in our libdruntime makefile, we shouldn't
>> generate the .di files anymore. Instead we should directly install
>> the .d files.
>
> I'm having a similar problem trying to build dub.
>
> If you download the dub source from GitHub and try and build using GDC, you get this:
>
> $ DC=gdmd ./build.sh
> Generating version file...
> Running gdmd...
> /opt/gdc/include/d/4.8.2/x86_64-unknown-linux-gnu/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code
> /opt/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)

Yeah, this is the same error that made me necro this thread.

Johannes: Is the libdruntime Makefile change going to be tricky, do you think? Or will stripping the -fintfc flags do?

On 17 October 2013 10:09, Johannes Pfau <nospam@example.com> wrote:
> Am Wed, 16 Oct 2013 23:34:11 +0100
> schrieb Iain Buclaw <ibuclaw@ubuntu.com>:
>
>> >
>> >
>> > Hi, sorry for the necro, but this discussion seemed to be somehow relevant to the problem I'm currently having. I have built GDC for ARM (on a Raspberry Pi) and I wanted to build dub [1]. This build fails with the following error:
>> >
>> > /usr/local/stow/gdc-4.8.1/include/d/4.8.1/arm-linux-gnueabihf/core/time.di:224:
>> > Error: this cannot be interpreted at compile time, because it has no
>> > available source code
>> > /usr/local/stow/gdc-4.8.1/include/d/4.8.1/std/net/curl.d:195:
>> > called from here: dur(2L)
>> >
>> > Is there any way to emit the plain .d files when building GDC, or some other workaround...?
>> >
>> > Actually, as I was typing this, it seems there is a workaround [2]. Still, there must be a nicer way? I must admit I don't get the whole .di thing.
>> >
>>
>> On Ubuntu, there is no workaround other than patching gcc proper with the Ubuntu patches for multiarch.
>
> Wait - this is a different problem. It's not a path problem, it's really a .di/.d problem.
>
> DMD seems to ship .d include files for druntime now, they're no longer shipping the .di files. The archlinux packages even do this for gdc. Some stuff now depends on this, as having the source code available allows more stuff to work in ctfe.
>
> We have to fix this in our libdruntime makefile, we shouldn't generate the .di files anymore. Instead we should directly install the .d files.

1. gdc looks for both .d and .di files in the include paths, so that is not the problem...

2. The .di file generation should still be kept around to act as a sanity check to make sure that all is useful for the target platform/architecture.


-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 17 October 2013 at 16:31:21 UTC, Iain Buclaw wrote:
> 1. gdc looks for both .d and .di files in the include paths, so that
> is not the problem...

Isn't this done in front-end? If .di file is found, *.d won't be searched.

On Thursday, 17 October 2013 at 09:10:43 UTC, Johannes Pfau wrote:
> DMD seems to ship .d include files for druntime now, they're no longer
> shipping the .di files. The archlinux packages even do this for gdc.
> Some stuff now depends on this, as having the source code available
> allows more stuff to work in ctfe.

And so does LDC. Actually, I'd be somewhat surprised if the Phobos test suite still passed without core.time being CTFEable.

David

On Thursday, 17 October 2013 at 16:35:48 UTC, Dicebot wrote:
> On Thursday, 17 October 2013 at 16:31:21 UTC, Iain Buclaw wrote:
>> 1. gdc looks for both .d and .di files in the include paths, so that
>> is not the problem...
>
> Isn't this done in front-end? If .di file is found, *.d won't be searched.

DMD does it this way, according to http://dlang.org/dmd-linux.html#interface_files

"D interface files can be created by the compiler from a D source file by using the -H switch to the compiler. D interface files have the .di file extension. When the compiler resolves an import declaration, it first looks for a .di D interface file, then it looks for a D source file."

That way the compilation would still get stuck, wouldn't it?

On Oct 17, 2013 6:20 PM, "David Nadlinger" <code@klickverbot.at> wrote:
>
> On Thursday, 17 October 2013 at 09:10:43 UTC, Johannes Pfau wrote:
>>
>> DMD seems to ship .d include files for druntime now, they're no longer shipping the .di files. The archlinux packages even do this for gdc. Some stuff now depends on this, as having the source code available allows more stuff to work in ctfe.
>
>
> And so does LDC. Actually, I'd be somewhat surprised if the Phobos test
suite still passed without core.time being CTFEable.
>

I'll have to re-check this. At the last time I looked, the interface file generation part of the front end did not omit the bodies of functions defined in modules.   I may perhaps be getting confused with version statements though. ;)

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

On Thursday, 17 October 2013 at 22:15:07 UTC, Iain Buclaw wrote:
> I'll have to re-check this. At the last time I looked, the interface file
> generation part of the front end did not omit the bodies of functions
> defined in modules.

It does now (unless -inline is given for DMD, or -Hkeep-all-bodies for LDC).

David

Am Tue, 24 Sep 2013 16:02:11 +0200
schrieb "eles" <eles@eles.com>:

[...]

Damn, I hate shell scripts / Makefiles: https://github.com/jpf91/GDC/commit/d9a6e38dd140b9a98ce694b2073714983c7af6a3

BTW: We could make this more failsafe by using "find" to search the source directory recursively. This way we wouldn't have the list all subfolders in the Makefile. But that only works if we copy all files to the same destination, we couldn't copy some files to ${include}/${target_triplet} as we do now.