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!

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

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.

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.

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

Thank you very much guys! This is incredibly important work.

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?

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.

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!

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.