On 16 October 2013 20:26, Stefan Frijters <sfrijt...@gmail.com> wrote:
> On Tuesday, 24 September 2013 at 14:48:44 UTC, Iain Buclaw wrote:
>>
>> On 24 September 2013 15:32, eles <e...@eles.com> wrote:
>>>
>>> On Tuesday, 24 September 2013 at 14:16:53 UTC, Johannes Pfau wrote:
>>>>
>>>>
>>>> Am Tue, 24 Sep 2013 16:02:11 +0200
>>>> schrieb "eles" <e...@eles.com>:
>>>>
>>>>> Hi,
>>>>>
>>>>> After compiling/installing the HEAD version of gdc in /opt/gdc4.9, I
>>>>> have:
>>>>> [...]
>>>>
>>>>
>>>>
>>>> Those files should be in
>>>> /opt/gdc-4.9/include/d/4.9.0/x86_64-unknown-linux-gnu/
>>>
>>>
>>>
>>> Indeed, but only the .di files, nothing about the .d
>>>
>>> $ls /opt/gdc-4.9/include/d/4.9.0/x86_64-unknown-linux-gnu/core/
>>> atomic.di cpuid.di exception.di memory.di simd.di sync time.di
>>> bitop.di demangle.di math.di runtime.di stdc sys
>>> vararg.di
>>>
>>> $find . -name 'atomic.d*'
>>> ./include/d/4.9.0/x86_64-unknown-linux-gnu/32/core/atomic.di
>>> ./include/d/4.9.0/x86_64-unknown-linux-gnu/core/atomic.di
>>>
>>> which is OK, as the .d should not be required, but still it is an
>>> asymmetry
>>> wrt phobos.
>>
>>
>> IIRC, the idea behind was being that compiler generated interface
>> files produced would emit only relevant declarations for the target
>> (ie: version(X86) { ... } else version (X86_64) { ... } would be
>> condensed down to just one or the other). So far this has not
>> happened - but then again, not much has been done in the way of
>> cleaning up what gets spewed out of compiler generated interface files
>> either...
>
>
> 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.
You are required to set:
CPATH=/usr/include/<arch>
LIBRARY_PATH=/usr/lib/<arch>
So that a vanilla gcc is able to find headers and libraries to compile
and link programs
Regards
--
Iain Buclaw
*(p < e ? p++ : p) = (c & 0x0f) + '0';
