> Aha, oops, I have the same 2060L, but that is presumably because I forgot to 'git checkout arm', and the master branch on Johannes' fork is not up-to-date. The reason why this works while normal GDC doesn't is that this is so old it doesn't include some explicit architecture static ifs that were added later (and for which ARM was not available for some time).
>
> I'm going to let this stuff rebuild overnight...

My build, from GDC master, went really well until it got to libphobos and then there were many architecture specific bits of code that just didn't include any ARM directives so it's probably currently impossible to build the latest libphobos on ARM.  I tried comparing the ARM fork but it was massively different and it looks like libphobos has been mostly rewritten since then.

I don't really understand why there are so many .d files that just seem to wrap standard os stuff - why not just use the standard installed C headers and avoid all of this overhead that needs maintaining ?

Interestingly the gcc Go compiler that is also included with gcc 4.8 built and installed first time so I'm rather tempted to just to give up with D as this point after a valiant battle for the last few days.

On Tuesday, 15 October 2013 at 22:28:59 UTC, Andrew wrote:
> I don't really understand why there are so many .d files that just seem to wrap standard os stuff - why not just use the standard installed C headers and avoid all of this overhead that needs maintaining ?

Those .d files are essentially just that - ported C headers so that you don't need to declared these functions manually. You can easily re-generated those from actual system C headers using tool like https://github.com/jacob-carlborg/dstep

> Interestingly the gcc Go compiler that is also included with gcc 4.8 built and installed first time so I'm rather tempted to just to give up with D as this point after a valiant battle for the last few days.

Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this.

P.S. I'd recommend to try to contact Johannes Pfau and ask if he has any plans for updating his ARM Phobos fork to recent version. Such changes should be probably integrated Phobos upstream eventually.

After roughly hacking all of the 'static assert "unimplemented"' lines in libphobos to just do whatever X86 does, I got it to build and install. Now I'm on 2063L and now hello world builds to 8MB instead of 2MB (although it strips to 760k - twice the previous version).

So now I resume my quest to build vibe.d by first trying to build dub and I get :-

andrew@islay:~/dub$ ./build.sh
Generating version file...
Running gdmd...
/usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code
/usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)

line 224 is trying to instantiate a Duration object. Any ideas ?

> Unfortunately, this is an area where difference in developer count is really notable. It is a dead end - support for more exotic platforms like ARM is lacking because there too few people who need it and new bypassers are scared from further investigation because of lacking support. There is hardly anything we can do until some volunteer will appear who is willing to champion this.

I was hoping to actually learn D before I had to maintain it :-)

ARM is hardly exotic, it's the best selling CPU by a large margin. I bet even Microsoft ships more ARM Windows licences than it does Intel now.

I'll have a look at that dstep util and see if I can contribute some patches back in order to save some other hapless fool like myself from suffering the same pain.

Thanks for your patience supporting me BTW.

On 10/15/13 3:38 PM, Dicebot wrote:

> Unfortunately, this is an area where difference in developer count is really notable. It is a dead
> end - support for more exotic platforms like ARM is lacking because there too few people who need it
> and new bypassers are scared from further investigation because of lacking support. There is hardly
> anything we can do until some volunteer will appear who is willing to champion this.

I think you mean catch-22 rather than dead-end.  There's not more people helping support ARM due to ARM not yet working well, so there's no developers.

ARM's not exotic, it's just not on as many people's desktops.  Thats been changing rapidly over the last several years.

> andrew@islay:~/dub$ ./build.sh
> Generating version file...
> Running gdmd...
> /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code
> /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)
>
> line 224 is trying to instantiate a Duration object. Any ideas ?

Giving up on dub, I tried niaively to build one of the vibe.d samples directly :-

andrew@islay:~/vibe.d/examples/http_server/source$ gdmd -I~/vibe.d/source app.d
/data/home/andrew/vibe.d/source/vibe/stream/ssl.d:43: error: module bio is in file 'deimos/openssl/bio.d' which cannot be read

Looks like I'm missing some openssl dependencies, where do these come from as they don't appear to be part of phobos ?


Thanks

On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote:
>
>> andrew@islay:~/dub$ ./build.sh
>> Generating version file...
>> Running gdmd...
>> /usr/local/gdc/include/d/4.8.2/armv7l-unknown-linux-gnueabihf/core/time.di:224: error: this cannot be interpreted at compile time, because it has no available source code
>> /usr/local/gdc/include/d/4.8.2/std/net/curl.d:195: note: called from here: dur(2L)
>>
>> line 224 is trying to instantiate a Duration object. Any ideas ?
>
> Giving up on dub, I tried niaively to build one of the vibe.d samples directly :-
>
> andrew@islay:~/vibe.d/examples/http_server/source$ gdmd -I~/vibe.d/source app.d
> /data/home/andrew/vibe.d/source/vibe/stream/ssl.d:43: error: module bio is in file 'deimos/openssl/bio.d' which cannot be read
>
> Looks like I'm missing some openssl dependencies, where do these come from as they don't appear to be part of phobos ?
>
>
> Thanks

As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems...

> As far as I know deimos is a set of official (?) bindings for common C libraries. I don't know dub's build process but I assume that if the build script would have worked for you it would have attempted to clone this repo https://github.com/D-Programming-Deimos/openssl (you can find more bindings if you go up one level). My gdc build hadn't finished yet when I had to leave for work this morning, but I'll try to build dub tonight, to see if I run into the same problems...

I've been using a Cubieboard A20, it's much better than a RPi as it has 1GB RAM, dual core armv7 and much better IO including on-board SATA for $50. The gcc /gdc build takes around 2 - 3 hours on that. You'll probably run into the same libphobos issues that I had, since there are many places where there are no ARM headers.

On Wednesday, 16 October 2013 at 07:52:44 UTC, Andrew wrote:
> Giving up on dub, I tried niaively to build one of the vibe.d samples directly

This is something I have used with vibe.d in absence of dub (untested, from my memory):

git clone https://github.com/D-Programming-Deimos/openssl
git clone https://github.com/D-Programming-Deimos/libevent
git clone https://github.com/rejectedsoftware/vibe.d
cd myvibeapp
rdmd --compiler=gdmd2 -I../openssl/ -I../libevent -I../vibe.d/source -J./views/ -version=VibeLibeventDriver --build-only source/app.d

Usage of `rdmd` is crucial here as you need something to take care of compiling all imported modules. dmd/gdc/ldc don't do it on their own and you really don't want to track that module list manually ;)

rdmd sources are here (it is a small trivial D app):
https://github.com/D-Programming-Language/tools