On 17/10/13 00:34, Iain Buclaw wrote:
> 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

So, still worth using the deb source package instead of vanilla GCC, and running the patches?

I thought recent GCC supported multiarch out of the box?  See:
http://forum.dlang.org/post/koa0rg$1m4o$1@digitalmars.com

On 17 October 2013 07:17, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
> On 17/10/13 00:34, Iain Buclaw wrote:
>>
>> 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
>
>
> So, still worth using the deb source package instead of vanilla GCC, and running the patches?
>
> I thought recent GCC supported multiarch out of the box?  See: http://forum.dlang.org/post/koa0rg$1m4o$1@digitalmars.com
>

You could try compiling with --enable-multiarch.  But I haven't done so yet. :)

-- 
Iain Buclaw

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

On 17 October 2013 07:24, Iain Buclaw <ibuclaw@ubuntu.com> wrote:
> On 17 October 2013 07:17, Joseph Rushton Wakeling <joseph.wakeling@webdrake.net> wrote:
>> On 17/10/13 00:34, Iain Buclaw wrote:
>>>
>>> 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
>>
>>
>> So, still worth using the deb source package instead of vanilla GCC, and running the patches?
>>
>> I thought recent GCC supported multiarch out of the box?  See: http://forum.dlang.org/post/koa0rg$1m4o$1@digitalmars.com
>>
>
> You could try compiling with --enable-multiarch.  But I haven't done so yet. :)
>

s/compiling/configuring/

-- 
Iain Buclaw

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

On 17/10/13 08:24, Iain Buclaw wrote:
>> You could try compiling with --enable-multiarch.  But I haven't done so yet. :)
>>
>
> s/compiling/configuring/

Just rebuilding with 4.8.2 in any case, so I'll try that.  Though I have no alternative-architecture devices to test with. :-P

On 17/10/13 09:03, Joseph Rushton Wakeling wrote:
> On 17/10/13 08:24, Iain Buclaw wrote:
>>> You could try compiling with --enable-multiarch.  But I haven't done so yet. :)
>>>
>>
>> s/compiling/configuring/
>
> Just rebuilding with 4.8.2 in any case, so I'll try that.  Though I have no
> alternative-architecture devices to test with. :-P

While we're talking about configure options -- is --disable-multilib still needed?

On 17/10/13 08:24, Iain Buclaw wrote:
> On 17 October 2013 07:17, Joseph Rushton Wakeling
> <joseph.wakeling@webdrake.net> wrote:
>> On 17/10/13 00:34, Iain Buclaw wrote:
>>>
>>> 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
>>
>>
>> So, still worth using the deb source package instead of vanilla GCC, and
>> running the patches?
>>
>> I thought recent GCC supported multiarch out of the box?  See:
>> http://forum.dlang.org/post/koa0rg$1m4o$1@digitalmars.com
>>
>
> You could try compiling with --enable-multiarch.  But I haven't done so yet. :)

Well, it compiles fine and seems to run OK.  I have nothing to test it with in terms of building stuff for other architectures ...

On Thursday, 17 October 2013 at 08:28:03 UTC, Joseph Rushton Wakeling wrote:
> On 17/10/13 08:24, Iain Buclaw wrote:
>> On 17 October 2013 07:17, Joseph Rushton Wakeling
>> <joseph.wakeling@webdrake.net> wrote:
>>> On 17/10/13 00:34, Iain Buclaw wrote:
>>>>
>>>> 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
>>>
>>>
>>> So, still worth using the deb source package instead of vanilla GCC, and
>>> running the patches?
>>>
>>> I thought recent GCC supported multiarch out of the box?  See:
>>> http://forum.dlang.org/post/koa0rg$1m4o$1@digitalmars.com
>>>
>>
>> You could try compiling with --enable-multiarch.  But I haven't done so yet. :)
>
> Well, it compiles fine and seems to run OK.  I have nothing to test it with in terms of building stuff for other architectures ...

I'm going to reconfigure with --enable-multiarch and rebuild on my RPi. With some luck it will have compiled before I go to bed tonight. It *is* awfully slow for this kind of thing :-D

On 17/10/13 10:37, Stefan Frijters wrote:
> I'm going to reconfigure with --enable-multiarch and rebuild on my RPi. With
> some luck it will have compiled before I go to bed tonight. It *is* awfully slow
> for this kind of thing :-D

Let me know how you get on.  I really must get an RPi of my own -- last time I had my hands on one, no D compiler was at a point where it'd run on or produce binaries for the Pi.

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.

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)