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.

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.

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!

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).

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. :)

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/core/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

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/core/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