Hi guys, I've seen this post (http://www.digitalmars.com/d/archives/D/gnu/600.html) which suggests that a GDC cross compiler for ARM can be created.  I can build a "vanilla" arm-linux toolchain, patch gdc into it and succesfully build gdc & phobos.  But I get weird errors when I try to use arm-linux-gdc to compile & link.  I can't remember especially, and don't have the logs with me.
Can somebody give me some hints on what binutils/gcc/linux combination can be used to produce a working arm-linux-gdc?
Any particular hints in general?  I think I am just going to build an x86 gdc first off, to get to grips with some of the GDC issues - but I would quite like to get the compiler working for ARM.

Cheers
Brad

I've been trying occasionall to do that too, but specifically with DevKitARM (http://www.devkit.tk).  (I don't know how useful that would be for your purposes though, since DevKitARM is designed specifically for GBA and Gamecube, and not "general" ARM use). Once I finally got my MSYS/MinGW environment *correctly* set up it was pretty easy to add the D front end into it. I never tried building Phobos though, so I was unable to use classes or anything particularly useful. I've been kinda scared off of compiling Phobos for DevKitARM because of the garbage collection code. I've been waiting for the new simpified garbage collector that's supposed to be coming to GDC soon.

But, I've since found out that it's easy to rip the gc out of Phobos (Apperently just minor changes to dmain2.d), so I my have to give it another go when I get a chance.

Nick

"brad beveridge" <brad@nowhere.com> wrote in message news:cta5mq$16rq$1@digitaldaemon.com...
> Hi guys, I've seen this post
> (http://www.digitalmars.com/d/archives/D/gnu/600.html) which suggests that
> a GDC cross compiler for ARM can be created.  I can build a "vanilla"
> arm-linux toolchain, patch gdc into it and succesfully build gdc & phobos.
> But I get weird errors when I try to use arm-linux-gdc to compile & link.
> I can't remember especially, and don't have the logs with me.
> Can somebody give me some hints on what binutils/gcc/linux combination can
> be used to produce a working arm-linux-gdc?
> Any particular hints in general?  I think I am just going to build an x86
> gdc first off, to get to grips with some of the GDC issues - but I would
> quite like to get the compiler working for ARM.
>
> Cheers
> Brad

A colleague and I have managed to compile the GDC frontend for ARM, but we're having issues with building Phobos.
The error that Phobos issues is along the lines of - Cannot implicitly cast ubyte* to char*.
The problem, I think, lies with the GCC builtins, and the fact that ARM natively has unsigned chars for the default char type, but I have no idea how to fix it.

Any thoughts?

Brad

Brad wrote:

> A colleague and I have managed to compile the GDC frontend for ARM, but we're having issues with building Phobos.
> The error that Phobos issues is along the lines of - Cannot implicitly cast ubyte* to char*.
> The problem, I think, lies with the GCC builtins, and the fact that ARM natively has unsigned chars for the default char type, but I have no idea how to fix it.

Linux PPC has the same problem. David Friedman is working on a fix,
I think he will explicitly change "char" to "signed char", where needed?

Luckily, D defines the signedness of chars now - whereas C does not...
(chars are signed on Linux X86 and Mac OS X, but unsigned on Linux PPC)

--anders

Anders F Björklund wrote:

> Linux PPC has the same problem. David Friedman is working on a fix,
> I think he will explicitly change "char" to "signed char", where needed?
> 
> Luckily, D defines the signedness of chars now - whereas C does not...
> (chars are signed on Linux X86 and Mac OS X, but unsigned on Linux PPC)
> 
> --anders

Thanks for the quick reply.  Do you know roughly where abouts these changes should be made?  David?  I am quite keen to have a play with D on my Linux ARM machines :)

Brad

brad@domain.invalid wrote:

> Thanks for the quick reply.  Do you know roughly where abouts these changes should be made?  David?  I am quite keen to have a play with D on my Linux ARM machines :)

Not really. The usual workaround on Linux PPC is to add a CFLAGS
of -fsigned-char, but GDC's Phobos doesn't really like that...

See:
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/970
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/972

I guess you could just insert a truckload of casts or something ?
(otherwise you would have to wait for the next version of GDC...)

--anders

PS. As you might have guessed, I went back to testing
    D on Mac OS X and Linux X86 instead of Linux PPC.

brad@domain.invalid wrote:
> Anders F Björklund wrote:
> 
>> Linux PPC has the same problem. David Friedman is working on a fix,
>> I think he will explicitly change "char" to "signed char", where needed?
>>
>> Luckily, D defines the signedness of chars now - whereas C does not... (chars are signed on Linux X86 and Mac OS X, but unsigned on Linux PPC)
>>
>> --anders
> 
> 
> Thanks for the quick reply.  Do you know roughly where abouts these changes should be made?  David?  I am quite keen to have a play with D on my Linux ARM machines :)
> 
> Brad

Brad,

Try the attached patch.  I have not tested it on one of the affected platforms, but I think it will work.

David

On Sun, 20 Feb 2005 21:27:53 -0500, David Friedman wrote:

> brad@domain.invalid wrote:
>> Anders F Björklund wrote:
>> 
>>> Linux PPC has the same problem. David Friedman is working on a fix, I think he will explicitly change "char" to "signed char", where needed?
>>>
>>> Luckily, D defines the signedness of chars now - whereas C does not... (chars are signed on Linux X86 and Mac OS X, but unsigned on Linux PPC)
>>>
>>> --anders
>> 
>> 
>> Thanks for the quick reply.  Do you know roughly where abouts these changes should be made?  David?  I am quite keen to have a play with D on my Linux ARM machines :)
>> 
>> Brad
> 
> Brad,
> 
> Try the attached patch.  I have not tested it on one of the affected platforms, but I think it will work.

In a follow up to this, we (Brad & I) have got this working with the following additional
changes (on top of the patch from David). Most of this should be applicable to other
people attempting to cross compile. Please excuse the formatting of the changes.
We now have a cross-compiling gdc executable, and it appears to be able to use the
libphobos std library (at least the example wc.d from the website works properly,
haven't done any other testing yet).

phobos/std/math.d
Line 85. Change:
real modf(real x, inout real y) { return std.c.math.modfl(x,&y); } to:
real modf(real x, inout real y) { return std.c.math.modfl(x,cast(double *)&y); }

Had to edit boehm-gc/Makefile to use the arm-linux-gcc cross compiler, instead of native
gcc
(lack of it caused the  R_ARM_PC24 relocation against SEC_MERGE section errors, due
to mixed architecture objects in libphobos.a).

In phobos/Makefile.in (to accomodate the fact that compiled files won't be executable

--- Makefile.in 2005-01-09 08:21:39.000000000 +1300
+++ Makefile.in.2       2005-02-21 16:04:53.000000000 +1300
@@ -33,6 +33,7 @@
 # Not used since it goes into libphobos.spec
 LIBS=@LIBS@
 CC=@CC@
+HOSTCC=gcc # Should do this properly using autoconf
 DMD=@DMD@

 # For recls
@@ -123,6 +124,8 @@
 # need frac-ac: frag-ac.in,etc.
 CONFIG_D_FRAGMENTS = config/config-head frag-ac frag-gen frag-math config/config-mid config/config-tail

+config/gen_config1.o: config/gen_config1.c
+       $(HOSTCC) -c -o $@ $< $(CFLAGS)
 gen_config1: config/gen_config1.o
        $(CC) -o $@ $^

@@ -131,15 +134,17 @@

 gcc/config.d: $(CONFIG_D_FRAGMENTS)
        cat $^ > $@
-
+config/gen_math.o: config/gen_math.c
+       $(HOSTCC) -c -o $@ $< $(CFLAGS)
 gen_math: config/gen_math.o
-       $(CC) -o $@ $^
+       $(HOSTCC) -o $@ $^
 frag-math: gen_math
        ./gen_math > $@

 config/gen_unix.o: config/gen_unix.c config/makestruct.h
+       $(HOSTCC) -c -o $@ $< $(CFLAGS)
 gen_unix: config/gen_unix.o
-       $(CC) -o $@ $^
+       $(HOSTCC) -o $@ $^

 frag-unix: gen_unix
        ./gen_unix > $@