www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - GDC ARM beta #1 (with binary releases!)

reply Johannes Pfau <nospam example.com> writes:
I'm happy to announce the first GDC ARM beta on behalf of the GDC
team :)

ARM support is now at a point where the automated tests (test suite,
unit tests) pass and we're ready for feedback from real world usage.
All changes have been fully integrated into the standard GDC sources
which also means we're currently using the 2.064 frontend. ARM support
is currently limited to ARM/GNU Linux, i.e. GlibC. (This especially
means Android and bare metal programming are not officially supported).

Please report all bugs to
http://bugzilla.gdcproject.org/

If you're sure that the bug is a bug in phobos/druntime/DMD frontend
and not GDC specific please report it to
https://d.puremagic.com/issues

==== Getting the ARM beta ==== 

* All necessary code changes have been merged into Druntime, Phobos and
  GDC and you can simply get the latest GDC sources and build them on
  ARM. ( http://wiki.dlang.org/GDC/Installation/Generic )
* GDC is also part of the official Archlinux ARM repositories. To get
  GDC for Archlinux ARM, simply use these commands:
      pacman -S gdc libgphobos-devel
  You can also get dub on Archlinux ARM by executing
      pacman -S dub
  Many thanks to Dicebot for maintaining the Archlinux packages.
* We provide binary cross compilers for windows X86 (32/64bit) and Linux
  x86 (32/64bit). We also provide 'native' compilers which run directly
  on ARM machines.
  http://gdcproject.org/downloads/
  Note: Linux distribution packages or building from source should be
  preferred.


==== Precompiled GDC binaries ====

Precompiled toolchains are available for ARM hardfloat and ARM
softfloat systems. These toolchains target systems with relatively
recent glibc and linux kernel (GlibC >= 2.14, Linux >= 2.6.32).

To check if you need the hard- or softfloat version run gcc -v where
gcc is a working gcc for your ARM target. Then look for --with-float=
in the output: --with-float=soft <==> softfloat
--with-float=hard <==> hardfloat

--with-float=softfp:
We have no special binaries for these systems. Either compile GDC from
sources or use the softfloat binaries. The softfloat binaries should
work in 99% of all cases. The only known exception is using floating
point functions in fibers, a 'softfp' toolchain is required in this
case.


To compile for ARM simply use this gdc executable:
./arm-gdcproject-linux-gnueabi[hf]/bin/arm-gdcproject-linux-gnueabi[hf]-gdc

Note: The toolchain directories are write protected. If you want to
change this, use chmod +w -R arm-gdcproject-linux-gnueabi[hf].

For more information on how to use additional libraries with the cross
compilers, see 
http://crosstool-ng.org/hg/crosstool-ng/raw-file/e11a8a2e225d/docs/5%20-%20Using%20the%20toolchain.txt

==== Known issues ====

Known ARM-specific issues
* std.internal.math.gammafunction.d is not ported yet (Help here is
  very appreciated!)
* Array ops are evaluated in reverse order (WIP, FE 2.065)
  http://bugzilla.gdcproject.org/show_bug.cgi?id=8

Known issues with the binary builds
* If you extract 7z files and are asked if you want to overwrite files,
  answer yes (toolchains are built on case sensitive filesystems,
  extracting on case insensitive filesystems will cause this warning)
* Use the arm-...-gdc.exe executables and not bin/arm.../gdc.exe.
* Unfortunately there's no multilib support for now. We use
  crosstool-NG to build these toolchains and multilib support in
  crosstool-NG is broken. However, this might change in the next few
  months.
Mar 17 2014
next sibling parent Piotr Szturmaj <bncrbme jadamspam.pl> writes:
W dniu 2014-03-17 15:05, Johannes Pfau pisze:
 I'm happy to announce the first GDC ARM beta on behalf of the GDC
 team :)

 ARM support is now at a point where the automated tests (test suite,
 unit tests) pass and we're ready for feedback from real world usage.
 All changes have been fully integrated into the standard GDC sources
 which also means we're currently using the 2.064 frontend. ARM support
 is currently limited to ARM/GNU Linux, i.e. GlibC. (This especially
 means Android and bare metal programming are not officially supported).

 Please report all bugs to
 http://bugzilla.gdcproject.org/

 If you're sure that the bug is a bug in phobos/druntime/DMD frontend
 and not GDC specific please report it to
 https://d.puremagic.com/issues
Many thanks for Johannes, GDC team and others involved. You did a great job! I'm already using GDC ARM compiler with good results. Btw. to anyone interested: To ensure stability of further development, we need an ARM/Linux auto tester. If anyone is willing to host an ARM box, please contact me by email (my Internet connection is not 100% reliable).
Mar 17 2014
prev sibling next sibling parent reply Manu <turkeyman gmail.com> writes:
On 18 March 2014 00:05, Johannes Pfau <nospam example.com> wrote:

 ...
Awesome work guys! This is a landmark moment! :) What's the status on baremetal, bionic, and iOS?
Mar 17 2014
next sibling parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 18 Mar 2014 02:07:11 +1000
schrieb Manu <turkeyman gmail.com>:

 On 18 March 2014 00:05, Johannes Pfau <nospam example.com> wrote:
 
 ...
Awesome work guys! This is a landmark moment! :) What's the status on baremetal, bionic, and iOS?
baremetal: Timo Sintonen and Mike post updates on the D.gnu newsgroup now and then. Timo uses the standard C library and libgcc IIRC which makes it easier to get higher level stuff like exceptions working. Mike uses a 100% baremetal approach where all code is in D (or D/inline ASM). https://bitbucket.org/timosi/minlibd/ https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study Bionic: I don't know if anyone is working on bionic/ARM/gdc. I know that there were some druntime updates for x86/Bionic recently. iOS: I don't know about gdc/iOS but there seems to be some work on this for LDC: http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net
Mar 17 2014
parent reply Dan Olson <zans.is.for.cans yahoo.com> writes:
Johannes Pfau <nospam example.com> writes:

 iOS:
 I don't know about gdc/iOS but there seems to be some work on this
 for LDC:
 http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net
I tried adding iOS support to GDC a year ago, but the arm--darwin target is missing in gcc since 4.2. It was turning into a lot of work to add arm-darwin back into 4.8. LDC has an advantage for targeting iOS since Apple uses and contributes to LLVM. Much of D works today on iOS (armv7) except TLS and issues with getting correct "real" type when cross-compiling, though Kai has a solution for that. -- Dan
Mar 17 2014
parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 18 Mar 2014 07:30, "Dan Olson" <zans.is.for.cans yahoo.com> wrote:
 Johannes Pfau <nospam example.com> writes:

 iOS:
 I don't know about gdc/iOS but there seems to be some work on this
 for LDC:
 http://forum.dlang.org/thread/m2txc2kqxv.fsf comcast.net
I tried adding iOS support to GDC a year ago, but the arm--darwin target is missing in gcc since 4.2. It was turning into a lot of work to add arm-darwin back into 4.8. LDC has an advantage for targeting iOS since Apple uses and contributes to LLVM. Much of D works today on iOS (armv7) except TLS and issues
GDC has tls emulation routines in its druntime. Once it is properly hooked into the GC (all attempts I've tried currently get deadlocked) then the LDC guys can reuse parts of it to work their backend.
 with getting correct "real" type when cross-compiling, though Kai has a
 solution for that.
Really? That is a problem? I'm not familiar with LDC or LLVM but I would at least expect the backend be able to provide that information on command. Or is this the fact that they still use native reals for CTFE? If so, then you can look at longdouble implementation in either DMD MSVC or GDC for that.
Mar 18 2014
parent "David Nadlinger" <code klickverbot.at> writes:
On Tuesday, 18 March 2014 at 08:04:21 UTC, Iain Buclaw wrote:
 Really? That is a problem? I'm not familiar with LDC or LLVM 
 but I would at
 least expect the backend be able to provide that information on 
 command.
 Or is this the fact that they still use native reals for CTFE?  
 If so, then
 you can look at longdouble implementation in either DMD MSVC or 
 GDC for that.
It is indeed only a question of polishing Kai's implementation of 'real' operations on the basis of llvm::APFloat, which then also allows us to drop Rainer's longdouble code for MSVC builds. David
Mar 18 2014
prev sibling parent "Joakim" <joakim airpost.net> writes:
On Monday, 17 March 2014 at 16:07:33 UTC, Manu wrote:
 On 18 March 2014 00:05, Johannes Pfau <nospam example.com> 
 wrote:

 ...
Awesome work guys! This is a landmark moment! :) What's the status on baremetal, bionic, and iOS?
Android keeps coming up in this thread, so let me address that. The main druntime now has decent support for bionic, with 31 out of 38 modules' unit tests passing. Emulated TLS is necessary for the rest of bionic, it looks like GDC just needs to wire in their existing implementation of emulated TLS. I'm not sure if exception handling varies on Android/ARM, haven't looked into that. It should be pretty straightforward to put these existing pieces together and get GDC working with Android, someone just needs to do it.
Mar 18 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
Vote up!

http://www.reddit.com/r/programming/comments/20n3yw/gdcarm_beta_1_d_programming_language_with_gcc/

https://news.ycombinator.com/newest (find it and vote it)

https://twitter.com/D_Programming/status/445607521752215552

https://www.facebook.com/dlang.org/posts/10202145218805462?stream_ref=10


Andrei
Mar 17 2014
parent reply simendsjo <simendsjo gmail.com> writes:
On 03/17/2014 06:11 PM, Andrei Alexandrescu wrote:
 Vote up!
(...)
 https://news.ycombinator.com/newest (find it and vote it)
Currently here (nr. 184): https://news.ycombinator.com/x?fnid=dKZJeV9oxnVX2eOw0VUBlt If not, search for "GDC".
Mar 17 2014
parent "Mengu" <mengukagan gmail.com> writes:
On Monday, 17 March 2014 at 20:32:13 UTC, simendsjo wrote:
 On 03/17/2014 06:11 PM, Andrei Alexandrescu wrote:
 Vote up!
(...)
 https://news.ycombinator.com/newest (find it and vote it)
Currently here (nr. 184): https://news.ycombinator.com/x?fnid=dKZJeV9oxnVX2eOw0VUBlt If not, search for "GDC".
for such searches, i suggest http://hn.algolia.com/.
Mar 17 2014
prev sibling next sibling parent reply "Martin" <email address.com> writes:
Hi,

first of all: thanks for the great work!

I've downloaded and tried the pre built toolchains for windows
(x86 and x64) on a hello world example and while they worked -
the executable produced the desired output - the file consisting
of just the writeln() call is 10 MByte in size.

I've just used the 'arm-gdcproject-linux-gnueabihf-gdc.exe'.

Are there some additional steps that I should be doing?

Take care,
Martin
Mar 17 2014
parent Johannes Pfau <nospam example.com> writes:
Am Mon, 17 Mar 2014 21:14:17 +0000
schrieb "Martin" <email address.com>:

 Hi,
 
 first of all: thanks for the great work!
 
 I've downloaded and tried the pre built toolchains for windows
 (x86 and x64) on a hello world example and while they worked -
 the executable produced the desired output - the file consisting
 of just the writeln() call is 10 MByte in size.
 
 I've just used the 'arm-gdcproject-linux-gnueabihf-gdc.exe'.
 
 Are there some additional steps that I should be doing?
 
 Take care,
 Martin
The phobos/druntime standard libraries shipped with the toolchains contain debug information and this causes big executables. You can use arm-gdcproject-linux-gnueabihf-strip.exe on the file to reduce the size. (but this also removes debug information, exception backtraces will probably not show function names then. strip also has some options to control what exactly is removed)
Mar 17 2014
prev sibling next sibling parent "inout" <inout gmail.com> writes:
On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)

 ARM support is now at a point where the automated tests (test 
 suite,
 unit tests) pass and we're ready for feedback from real world 
 usage.
 All changes have been fully integrated into the standard GDC 
 sources
 which also means we're currently using the 2.064 frontend. ARM 
 support
 is currently limited to ARM/GNU Linux, i.e. GlibC. (This 
 especially
 means Android and bare metal programming are not officially 
 supported).

 Please report all bugs to
 http://bugzilla.gdcproject.org/

 If you're sure that the bug is a bug in phobos/druntime/DMD 
 frontend
 and not GDC specific please report it to
 https://d.puremagic.com/issues

 ==== Getting the ARM beta ====

 * All necessary code changes have been merged into Druntime, 
 Phobos and
   GDC and you can simply get the latest GDC sources and build 
 them on
   ARM. ( http://wiki.dlang.org/GDC/Installation/Generic )
 * GDC is also part of the official Archlinux ARM repositories. 
 To get
   GDC for Archlinux ARM, simply use these commands:
       pacman -S gdc libgphobos-devel
   You can also get dub on Archlinux ARM by executing
       pacman -S dub
   Many thanks to Dicebot for maintaining the Archlinux packages.
 * We provide binary cross compilers for windows X86 (32/64bit) 
 and Linux
   x86 (32/64bit). We also provide 'native' compilers which run 
 directly
   on ARM machines.
   http://gdcproject.org/downloads/
   Note: Linux distribution packages or building from source 
 should be
   preferred.


 ==== Precompiled GDC binaries ====

 Precompiled toolchains are available for ARM hardfloat and ARM
 softfloat systems. These toolchains target systems with 
 relatively
 recent glibc and linux kernel (GlibC >= 2.14, Linux >= 2.6.32).

 To check if you need the hard- or softfloat version run gcc -v 
 where
 gcc is a working gcc for your ARM target. Then look for 
 --with-float=
 in the output: --with-float=soft <==> softfloat
 --with-float=hard <==> hardfloat

 --with-float=softfp:
 We have no special binaries for these systems. Either compile 
 GDC from
 sources or use the softfloat binaries. The softfloat binaries 
 should
 work in 99% of all cases. The only known exception is using 
 floating
 point functions in fibers, a 'softfp' toolchain is required in 
 this
 case.


 To compile for ARM simply use this gdc executable:
 ./arm-gdcproject-linux-gnueabi[hf]/bin/arm-gdcproject-linux-gnueabi[hf]-gdc

 Note: The toolchain directories are write protected. If you 
 want to
 change this, use chmod +w -R arm-gdcproject-linux-gnueabi[hf].

 For more information on how to use additional libraries with 
 the cross
 compilers, see
 http://crosstool-ng.org/hg/crosstool-ng/raw-file/e11a8a2e225d/docs/5%20-%20Using%20the%20toolchain.txt

 ==== Known issues ====

 Known ARM-specific issues
 * std.internal.math.gammafunction.d is not ported yet (Help 
 here is
   very appreciated!)
 * Array ops are evaluated in reverse order (WIP, FE 2.065)
   http://bugzilla.gdcproject.org/show_bug.cgi?id=8

 Known issues with the binary builds
 * If you extract 7z files and are asked if you want to 
 overwrite files,
   answer yes (toolchains are built on case sensitive 
 filesystems,
   extracting on case insensitive filesystems will cause this 
 warning)
 * Use the arm-...-gdc.exe executables and not 
 bin/arm.../gdc.exe.
 * Unfortunately there's no multilib support for now. We use
   crosstool-NG to build these toolchains and multilib support in
   crosstool-NG is broken. However, this might change in the 
 next few
   months.
Any love for us Mac users? I'd love to try it for Android/NDK development.
Mar 17 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)

 ARM support is now at a point where the automated tests (test 
 suite,
 unit tests) pass and we're ready for feedback from real world 
 usage.
 All changes have been fully integrated into the standard GDC 
 sources
 which also means we're currently using the 2.064 frontend. ARM 
 support
 is currently limited to ARM/GNU Linux, i.e. GlibC. (This 
 especially
 means Android and bare metal programming are not officially 
 supported).

 Please report all bugs to
 http://bugzilla.gdcproject.org/

 If you're sure that the bug is a bug in phobos/druntime/DMD 
 frontend
 and not GDC specific please report it to
 https://d.puremagic.com/issues

 ==== Getting the ARM beta ====

 * All necessary code changes have been merged into Druntime, 
 Phobos and
   GDC and you can simply get the latest GDC sources and build 
 them on
   ARM. ( http://wiki.dlang.org/GDC/Installation/Generic )
 * GDC is also part of the official Archlinux ARM repositories. 
 To get
   GDC for Archlinux ARM, simply use these commands:
       pacman -S gdc libgphobos-devel
   You can also get dub on Archlinux ARM by executing
       pacman -S dub
   Many thanks to Dicebot for maintaining the Archlinux packages.
 * We provide binary cross compilers for windows X86 (32/64bit) 
 and Linux
   x86 (32/64bit). We also provide 'native' compilers which run 
 directly
   on ARM machines.
   http://gdcproject.org/downloads/
   Note: Linux distribution packages or building from source 
 should be
   preferred.


 ==== Precompiled GDC binaries ====

 Precompiled toolchains are available for ARM hardfloat and ARM
 softfloat systems. These toolchains target systems with 
 relatively
 recent glibc and linux kernel (GlibC >= 2.14, Linux >= 2.6.32).

 To check if you need the hard- or softfloat version run gcc -v 
 where
 gcc is a working gcc for your ARM target. Then look for 
 --with-float=
 in the output: --with-float=soft <==> softfloat
 --with-float=hard <==> hardfloat

 --with-float=softfp:
 We have no special binaries for these systems. Either compile 
 GDC from
 sources or use the softfloat binaries. The softfloat binaries 
 should
 work in 99% of all cases. The only known exception is using 
 floating
 point functions in fibers, a 'softfp' toolchain is required in 
 this
 case.


 To compile for ARM simply use this gdc executable:
 ./arm-gdcproject-linux-gnueabi[hf]/bin/arm-gdcproject-linux-gnueabi[hf]-gdc

 Note: The toolchain directories are write protected. If you 
 want to
 change this, use chmod +w -R arm-gdcproject-linux-gnueabi[hf].

 For more information on how to use additional libraries with 
 the cross
 compilers, see
 http://crosstool-ng.org/hg/crosstool-ng/raw-file/e11a8a2e225d/docs/5%20-%20Using%20the%20toolchain.txt

 ==== Known issues ====

 Known ARM-specific issues
 * std.internal.math.gammafunction.d is not ported yet (Help 
 here is
   very appreciated!)
 * Array ops are evaluated in reverse order (WIP, FE 2.065)
   http://bugzilla.gdcproject.org/show_bug.cgi?id=8

 Known issues with the binary builds
 * If you extract 7z files and are asked if you want to 
 overwrite files,
   answer yes (toolchains are built on case sensitive 
 filesystems,
   extracting on case insensitive filesystems will cause this 
 warning)
 * Use the arm-...-gdc.exe executables and not 
 bin/arm.../gdc.exe.
 * Unfortunately there's no multilib support for now. We use
   crosstool-NG to build these toolchains and multilib support in
   crosstool-NG is broken. However, this might change in the 
 next few
   months.
I just want to say, thank you for all of your hard work. For those who have gotten gdc to this point. And I'll definitely be looking forward to seeing support for Android!
Mar 17 2014
prev sibling next sibling parent "Chris" <wendlec tcd.ie> writes:
Thank you very much guys! This is incredibly important work.
Mar 18 2014
prev sibling next sibling parent reply "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)
Thanks a lot for the pre-compiled binaries! That really opens up ARM development for a much wider audience. I'm encountering a problem with binaries built using the Windows-hosted cross-compiler; when trying to execute them on the ARM target, I get: "bash: ./hello: No such file or directory" The file is of course executable. What could cause this?
Mar 18 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Tue, 18 Mar 2014 18:56:39 +0000
schrieb "Jakob Ovrum" <jakobovrum gmail.com>:

 On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)
Thanks a lot for the pre-compiled binaries! That really opens up ARM development for a much wider audience. I'm encountering a problem with binaries built using the Windows-hosted cross-compiler; when trying to execute them on the ARM target, I get: "bash: ./hello: No such file or directory" The file is of course executable. What could cause this?
That error message is indeed great ;-) It's one of the following: * hardfloat/softfloat mismatch between your arm system and the cross compiler * glibc version on ARM system too old (<2.14) * linux kernel on ARM system too old (<2.6.32) * Other ABI mismatch Can you post some details about your ARM target? Linux distribution and hardware/CPU are most interesting.
Mar 18 2014
parent "Jakob Ovrum" <jakobovrum gmail.com> writes:
On Tuesday, 18 March 2014 at 19:19:24 UTC, Johannes Pfau wrote:
 Am Tue, 18 Mar 2014 18:56:39 +0000
 schrieb "Jakob Ovrum" <jakobovrum gmail.com>:

 On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of 
 the GDC
 team :)
Thanks a lot for the pre-compiled binaries! That really opens up ARM development for a much wider audience. I'm encountering a problem with binaries built using the Windows-hosted cross-compiler; when trying to execute them on the ARM target, I get: "bash: ./hello: No such file or directory" The file is of course executable. What could cause this?
That error message is indeed great ;-) It's one of the following: * hardfloat/softfloat mismatch between your arm system and the cross compiler * glibc version on ARM system too old (<2.14) * linux kernel on ARM system too old (<2.6.32) * Other ABI mismatch Can you post some details about your ARM target? Linux distribution and hardware/CPU are most interesting.
It's the OpenPandora 1GHz version, which has a TI DM3730 SoC. It runs Super Zaxxon (Pandora OS) which is based on Ångström GNU/Linux and runs kernel version 3.2.x. The problem was indeed floating point - needed to be softfp. Now works, thanks!
Mar 18 2014
prev sibling next sibling parent reply Iain Buclaw <ibuclaw gdcproject.org> writes:
On 17 March 2014 14:05, Johannes Pfau <nospam example.com> wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the GDC
 team :)
Johannes, I just looked at the permissions of two randomly tested tarballs, and I see the extracted contents is absent of any write permissions. More of an annoyance if you install via extract + move. No one likes a permission denied error when doing an operation from their own home directory. :o) Regards Iain.
Mar 23 2014
parent reply Johannes Pfau <nospam example.com> writes:
Am Sun, 23 Mar 2014 20:20:09 +0000
schrieb Iain Buclaw <ibuclaw gdcproject.org>:

 On 17 March 2014 14:05, Johannes Pfau <nospam example.com> wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the GDC
 team :)
Johannes, I just looked at the permissions of two randomly tested tarballs, and I see the extracted contents is absent of any write permissions. More of an annoyance if you install via extract + move. No one likes a permission denied error when doing an operation from their own home directory. :o) Regards Iain.
crosstool-NG does that by default to prevent people from installing libraries into the sysroot. But if you think the we should set the write permissions it's a simple change in the configuration, I just kept the default.
Mar 23 2014
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 23 March 2014 23:05, Johannes Pfau <nospam example.com> wrote:
 Am Sun, 23 Mar 2014 20:20:09 +0000
 schrieb Iain Buclaw <ibuclaw gdcproject.org>:

 On 17 March 2014 14:05, Johannes Pfau <nospam example.com> wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the GDC
 team :)
Johannes, I just looked at the permissions of two randomly tested tarballs, and I see the extracted contents is absent of any write permissions. More of an annoyance if you install via extract + move. No one likes a permission denied error when doing an operation from their own home directory. :o) Regards Iain.
crosstool-NG does that by default to prevent people from installing libraries into the sysroot. But if you think the we should set the write permissions it's a simple change in the configuration, I just kept the default.
I think it should be noted that these tarballs are meant to be kept separate from system install locations (incase someone misses the distinction).
Mar 24 2014
prev sibling next sibling parent "ian" <ianmga gmail.com> writes:
By the way, I verified this can also be used for bare metal ARM 
programming as described in

https://github.com/JinShil/D_Runtime_ARM_Cortex-M_study/wiki/1.0-Introduction

Very very cool,

  ian

On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)

 ARM support is now at a point where the automated tests (test 
 suite,
 unit tests) pass and we're ready for feedback from real world 
 usage.
 All changes have been fully integrated into the standard GDC 
 sources
 which also means we're currently using the 2.064 frontend. ARM 
 support
 is currently limited to ARM/GNU Linux, i.e. GlibC. (This 
 especially
 means Android and bare metal programming are not officially 
 supported).

 Please report all bugs to
 http://bugzilla.gdcproject.org/

 If you're sure that the bug is a bug in phobos/druntime/DMD 
 frontend
 and not GDC specific please report it to
 https://d.puremagic.com/issues

 ==== Getting the ARM beta ====

 * All necessary code changes have been merged into Druntime, 
 Phobos and
   GDC and you can simply get the latest GDC sources and build 
 them on
   ARM. ( http://wiki.dlang.org/GDC/Installation/Generic )
 * GDC is also part of the official Archlinux ARM repositories. 
 To get
   GDC for Archlinux ARM, simply use these commands:
       pacman -S gdc libgphobos-devel
   You can also get dub on Archlinux ARM by executing
       pacman -S dub
   Many thanks to Dicebot for maintaining the Archlinux packages.
 * We provide binary cross compilers for windows X86 (32/64bit) 
 and Linux
   x86 (32/64bit). We also provide 'native' compilers which run 
 directly
   on ARM machines.
   http://gdcproject.org/downloads/
   Note: Linux distribution packages or building from source 
 should be
   preferred.


 ==== Precompiled GDC binaries ====

 Precompiled toolchains are available for ARM hardfloat and ARM
 softfloat systems. These toolchains target systems with 
 relatively
 recent glibc and linux kernel (GlibC >= 2.14, Linux >= 2.6.32).

 To check if you need the hard- or softfloat version run gcc -v 
 where
 gcc is a working gcc for your ARM target. Then look for 
 --with-float=
 in the output: --with-float=soft <==> softfloat
 --with-float=hard <==> hardfloat

 --with-float=softfp:
 We have no special binaries for these systems. Either compile 
 GDC from
 sources or use the softfloat binaries. The softfloat binaries 
 should
 work in 99% of all cases. The only known exception is using 
 floating
 point functions in fibers, a 'softfp' toolchain is required in 
 this
 case.


 To compile for ARM simply use this gdc executable:
 ./arm-gdcproject-linux-gnueabi[hf]/bin/arm-gdcproject-linux-gnueabi[hf]-gdc

 Note: The toolchain directories are write protected. If you 
 want to
 change this, use chmod +w -R arm-gdcproject-linux-gnueabi[hf].

 For more information on how to use additional libraries with 
 the cross
 compilers, see
 http://crosstool-ng.org/hg/crosstool-ng/raw-file/e11a8a2e225d/docs/5%20-%20Using%20the%20toolchain.txt

 ==== Known issues ====

 Known ARM-specific issues
 * std.internal.math.gammafunction.d is not ported yet (Help 
 here is
   very appreciated!)
 * Array ops are evaluated in reverse order (WIP, FE 2.065)
   http://bugzilla.gdcproject.org/show_bug.cgi?id=8

 Known issues with the binary builds
 * If you extract 7z files and are asked if you want to 
 overwrite files,
   answer yes (toolchains are built on case sensitive 
 filesystems,
   extracting on case insensitive filesystems will cause this 
 warning)
 * Use the arm-...-gdc.exe executables and not 
 bin/arm.../gdc.exe.
 * Unfortunately there's no multilib support for now. We use
   crosstool-NG to build these toolchains and multilib support in
   crosstool-NG is broken. However, this might change in the 
 next few
   months.
Mar 23 2014
prev sibling next sibling parent reply "Dejan Lekic" <dejan.lekic gmail.com> writes:
Hi all, I am back from a winter holiday.

Just wanted to say this - I have been building working GDC on my 
ODROID-U2 for a month or so, and haven't seen any problems there 
so far.

ARM support is pretty good I would say. GDC guys have done some 
amazing work, and I am eternally grateful for everything. :)

Kudos!
Mar 24 2014
parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On 24 March 2014 09:15, Dejan Lekic <dejan.lekic gmail.com> wrote:
 Hi all, I am back from a winter holiday.

 Just wanted to say this - I have been building working GDC on my ODROID-U2
 for a month or so, and haven't seen any problems there so far.

 ARM support is pretty good I would say. GDC guys have done some amazing
 work, and I am eternally grateful for everything. :)

 Kudos!
Thanks Dejan. We should catch-up sometime. :)
Mar 24 2014
prev sibling parent reply "Ellery Newcomer" <ellery-newcomer utulsa.edu> writes:
On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)
Cool! Just tried building it with crosstools-ng on my poor old laptop, and 90 minutes in it gives me /home/ellery/Downloads/pitools/.build/src/gcc-custom/libphobos/libdruntime/c re/threadasm.S:387: Error: selected processor does not support ARM mode `vpop {d8-d15}' Any thoughts? My guesses are 1. set Default Instruction Set to thumb (?) or 2. the submodules didn't update on git pull. But I've gotten a working compiler out of this config before, from Mr. Pfau's fork a few months ago, so prolly not 1. I'd test these myself, but I don't have a spare 180 minutes tonight.. gdc-4.8 branch; gcc-4.8.1, should be the linaro source, but not sure
Apr 01 2014
parent Johannes Pfau <nospam example.com> writes:
Am Wed, 02 Apr 2014 05:02:09 +0000
schrieb "Ellery Newcomer" <ellery-newcomer utulsa.edu>:

 On Monday, 17 March 2014 at 14:07:13 UTC, Johannes Pfau wrote:
 I'm happy to announce the first GDC ARM beta on behalf of the 
 GDC
 team :)
Cool! Just tried building it with crosstools-ng on my poor old laptop, and 90 minutes in it gives me /home/ellery/Downloads/pitools/.build/src/gcc-custom/libphobos/libdruntime/c re/threadasm.S:387: Error: selected processor does not support ARM mode `vpop {d8-d15}' Any thoughts? My guesses are 1. set Default Instruction Set to thumb (?) or 2. the submodules didn't update on git pull. But I've gotten a working compiler out of this config before, from Mr. Pfau's fork a few months ago, so prolly not 1. I'd test these myself, but I don't have a spare 180 minutes tonight.. gdc-4.8 branch; gcc-4.8.1, should be the linaro source, but not sure
That's a strange GCC/binutils issue. The new Fiber ASM implementation needs a FPU which at least provides VFP instructions. Now according to GCC docs GCC only supports these FPUs(*). But if you don't specify one explicitly it still produces this error. (I guess binutils supports more FPUs and assumes an older default). The solution is to set "Use specific FPU" in crosstool-NG to 'vfp' or any other valid value. (*) http://gcc.gnu.org/onlinedocs/gcc/ARM-Options.html (-mfpu=name) Every value listed there works, only not specifying one fails
Apr 02 2014