Does anybody know if this is now fixed ? :-
https://bitbucket.org/goshawk/gdc/issue/120/fsection-anchors-broken-on-arm
I might be wrong but I could be facing this bug when trying to
run any of the vibe.d samples, here's an example :-
(gdb) cont
Continuing.
Program received signal SIGSEGV,
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
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
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
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
On Tuesday, 15 October 2013 at 22:52:42 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
On Tuesday, 15 October 2013 at 23:16:07 UTC, Brad Roberts wrote:
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
On Tuesday, 15 October 2013 at 23:03:15 UTC, Andrew wrote:
Thanks for your patience supporting me BTW.
You are welcome. D development is pure open-source movement with
all its pros and cons - almost anyone here will gladly help you
not only because we care about a good public image but
On Wednesday, 16 October 2013 at 09:11:16 UTC, Andrew wrote:
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
I'm a very happy man ! Everything is built and working including
dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to everybody for the help, now I can start learning D,
exploring vibe.d
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote:
I'm a very happy man ! Everything is built and working
including dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to
On Wednesday, 16 October 2013 at 19:18:53 UTC, Andrew wrote:
I'm a very happy man ! Everything is built and working
including dub and the http_server example from vibe.d.
It's slow to build, but it executes quickly and strips down to
about 3MB which is heavy but tolerable.
Thanks to
I've successfully built Pegged and I'm now trying to build vibe.d
which requires dub so ...
andrew@islay:~$ cd dub-0.9.18/
andrew@islay:~/dub-0.9.18$ ls
binbuild-files.txt CHANGELOG.md examples
LICENSE_DE.txt package.json source
build.cmd build.sh curl.lib installer
On Tuesday, 15 October 2013 at 12:31:49 UTC, Andrew wrote:
Any ideas what I'm doing wrong ?
Thanks for all of the hand-holding BTW.
What is your GDC version? Looks like one with pre-2.063 front-end
as it does not support `alias X = ...` syntax. vibe.d developers
do try to support latest two
What is your GDC version? Looks like one with pre-2.063
front-end as it does not support `alias X = ...` syntax. vibe.d
developers do try to support latest two released front-end
versions but it is not as easy as it sounds (I hope situation
will improve a lot once CI is finally up and
On Tuesday, 15 October 2013 at 14:38:32 UTC, Andrew wrote:
I think it's the latest version of GDC :-
https://github.com/jpf91/GDC/tree/arm
which apparently supports 2.062.
Ugh, don't know about ARM build but GDC itself currently supports
2.063.2 version for both 4.8 and 4.9 branch.
In the
On Tuesday, 15 October 2013 at 14:56:06 UTC, Dicebot wrote:
On Tuesday, 15 October 2013 at 14:38:32 UTC, Andrew wrote:
Is this something I can update easily ?
If rebuilding GDC from sources so that it will catch 2.063.2
frontend version is an option - it may help.
Looking at
Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2
support is also included in the ARM branch, cf. commit 1aa5755
from June 30, so you should have it already I think. Where did
you get the 2.062 info from?
2.062 was mentioned on the GDC website as the latest supported
D2. So I'm
On Tuesday, 15 October 2013 at 18:41:50 UTC, Andrew wrote:
Looking at https://github.com/jpf91/GDC/commits/arm , 2.063.2
support is also included in the ARM branch, cf. commit 1aa5755
from June 30, so you should have it already I think. Where did
you get the 2.062 info from?
2.062 was
On Tue, Oct 15, 2013 at 09:19:56PM +0200, Andrew wrote:
pragma(msg, __VERSION__);
```
2060L - seems I'm further advanced than everybody else :-)
Wow that's pretty old. The current language version supported by GDC is
2063L. You should probably consider upgrading GDC to at least 2.0.62
2060L - seems I'm further advanced than everybody else :-)
Sorry, I thought it was 2.052, but now I see it's well behind
since it should be 2.063. I'm rebuilding again from the master.
pragma(msg, __VERSION__);
```
2060L - seems I'm further advanced than everybody else :-)
On Tuesday, 15 October 2013 at 19:23:13 UTC, Andrew wrote:
2060L - seems I'm further advanced than everybody else :-)
Sorry, I thought it was 2.052, but now I see it's well behind
since it should be 2.063. I'm rebuilding again from the master.
Aha, oops, I have the same 2060L, but that is
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
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
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
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
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
Thanks Stefan, those were the instructions that I tried.
With GDC, is it possible to generate portable intermediate C code
so that I can compile D sources on the Mac and then just copy the
resultant C code to an ARM debian machine and build that there ?
That would allow me to work around the
On Monday, 14 October 2013 at 07:36:03 UTC, Andrew wrote:
Thanks Stefan, those were the instructions that I tried.
With GDC, is it possible to generate portable intermediate C
code so that I can compile D sources on the Mac and then just
copy the resultant C code to an ARM debian machine and
Hallelujah - it's built ! Thanks Stefan for the link to the ARM
fork, that and a pile of messing about with float ABI types and I
managed to get it built and installed on my Cubieboard A20 (ARM7
debian distro).
So now I compile Hello World and I get a 2MB executable ! This
compares with 8kb
On Monday, 14 October 2013 at 20:59:25 UTC, Andrew wrote:
So now I compile Hello World and I get a 2MB executable !
gdc makes kinda large executables... but with my gdc cross
compiler for arm, the hello world is 360 KB after stripping, but
I used printf instead of writefln. phobos is pretty
As Adam already said D on Pi is adventurous.
For MongoDB and web stuff, you should look into Vibe.d [0]. For
parsing I would suggest Pegged [1].
Welcome to D and Happy Hacking! :)
[0] http://vibed.org/
[1] https://github.com/PhilippeSigaud/Pegged
Thanks both. Well after several hours of
On Friday, 11 October 2013 at 07:09:17 UTC, Andrew wrote:
As Adam already said D on Pi is adventurous.
For MongoDB and web stuff, you should look into Vibe.d [0].
For parsing I would suggest Pegged [1].
Welcome to D and Happy Hacking! :)
[0] http://vibed.org/
[1]
On Thursday, 10 October 2013 at 19:49:15 UTC, Andrew wrote:
Hence my interest in D. I've spent a few hours trying to get
GDC working on my Pi which is proving to be a bitch but I'm
hoping that it will be worth it.
I haven't done a serious program on the Pi, but I was able to get
gdc and some
On Thursday, 10 October 2013 at 19:49:15 UTC, Andrew wrote:
Hi All,
I've been writing a MUD for a little while, initially using
Haskell but now using C. I develop on MacOS X but deploy to a
Raspberry Pi. I loved using Haskell especially using the Parsec
parser but unfortunately I couldn't
37 matches
Mail list logo
