Hi there, been trying to get GDC working on beos, im very interested in making it work and take all help i can get. But seems to be alot of linkage problems etc.

But anyways, a place to start? I have added d_ver_string thingie as beos and it works.

The pthread dependency, is that removable? As beos only has an incomplete extra lib for this.

i get alot of _Unwind* unresolved externals, sounds like its some lib version missmatch or something that does this .. dunno where tho, im going to try and crosscompile it from linux against the haiku tree as soon as i get haiku to compile on gcc4 :P

I know ordenary beos is gcc 2.95* so it wont work with beapi, but in haiku i have the option to compile gcc4 if i like :> And it starts to be so complete that im very positive it will be usable soon :>

Ahh and __libc_stack_end is missing, or was, havent seen it the last 30 compiles or so but was missing first time i tried to compile...

Anyways, im gonna try and get it running but i might need help from people that already have ported or the founder? :> If needed i can even setup this machine as a short term telnet machine for error checking :>

I think D can be a very good contribution to the beos comunity if it works and beapi works :>

Live long and prosper!
                        / Tomas on his way to perfection

Hi Tomas

I am working on making a gdc crosscompiler for PDAs using Windows CE on the ARM/Xscale processor (arm-wince-pe).  If you run into problems similar to the ones I've faced, I should be able to help.

Also, note that my advice is coming from GDC v0.18.  I haven't spent time upgrading to v0.19 yet because I just want to get a crosscompiler that creates working arm-wince-pe executables before I merge it into v0.19.

Tomas Wilhelmsson wrote:
> Hi there, been trying to get GDC working on beos, im very interested in
> making it work and take all help i can get. But seems to be alot of linkage
> problems etc.
> 
> But anyways, a place to start? I have added d_ver_string thingie as beos and
> it works.

A place to start, hmm.  I always find myself in gcc/d/phobos/configure tweaking the way phobos gets compiled.  I think a lot of it is just getting phobos and gdc to configure properly, otherwise it may cause you to extend phobos when you really don't need to.

d_ver_string - where is that?
I know I had to modify gcc/d/target-ver-syms.sh to get the gdc to provide correct builtin version flags.

> 
> The pthread dependency, is that removable? As beos only has an incomplete
> extra lib for this.

AFAIK, you should be able to use Windows threading functions as an alternative.  I might be wrong to assume that's the only alternative. If nothing else works, you're either going to have to rewrite phobos to not provide or use threading, or you will have to write in versions of the phobos threading functions that use BeOS thread support instead of POSIX or Windows.

> 
> i get alot of _Unwind* unresolved externals, sounds like its some lib
> version missmatch or something that does this .. dunno where tho, im going
> to try and crosscompile it from linux against the haiku tree as soon as i
> get haiku to compile on gcc4 :P

Could you post your error messages, please?

Also, when do you get these unresolved externals?  Is it during compilation of Phobos/gdc, or is this when you try and link together an executable and get "undefined reference" errors?

> 
> I know ordenary beos is gcc 2.95* so it wont work with beapi, but in haiku i
> have the option to compile gcc4 if i like :> And it starts to be so complete
> that im very positive it will be usable soon :>
> 
> Ahh and __libc_stack_end is missing, or was, havent seen it the last 30
> compiles or so but was missing first time i tried to compile...
> 
> Anyways, im gonna try and get it running but i might need help from people
> that already have ported or the founder? :> If needed i can even setup this
> machine as a short term telnet machine for error checking :>
> 
> I think D can be a very good contribution to the beos comunity if it works
> and beapi works :>
> 
> Live long and prosper!
>                         / Tomas on his way to perfection
> 

Good luck with your port!

Worked on it like crazy last night, had to do some hard coding to cbridge_math.c as it seems beos doesnt have __fpclassifyl :/

I think i missed std.c.beos folder as i cant find a way to make Makefile copy that to the damn folder :/ Any ideas? :>

Anyways here is the progress from last night:


$ gdc test.d /boot/develop/tools/gnuprod/lib/libgphobos.a
/boot/develop/tools/gnuprod/lib/libstdc++.a
/boot/develop/tools/gnuprod/lib/gcc/i586-pc-beos/3.4.3/libgcc.a
cc1d: warning: command line option "-Wno-multichar" is valid for
C/C++/ObjC/ObjC++ but not for D
$ ./test
Hello from D in BeOS!!!
$

Tried compiling Gregor:s bcd .. compiles fine, runs but no gccxml on beos :/

Posted it on
http://www.bebits.com/app/4376

And hope i will get some comments on parts that work and not so i can fix up the rest :>

The whole build process is a bitch as configunix.d (the generated file) has some size problems for some reason. When i recompile i will remember to copy the problem and post it :>

Live long and prosper!
				/ Tomas on his way to perfection

> AFAIK, you should be able to use Windows threading functions as an alternative.  I might be wrong to assume that's the only alternative. If nothing else works, you're either going to have to rewrite phobos to not provide or use threading, or you will have to write in versions of the phobos threading functions that use BeOS thread support instead of POSIX or Windows.

BeOS has a completely different native thread library:

http://www.beunited.org/bebook/The%20Kernel%20Kit/ThreadConcepts.html#Thread _and_Team_Concepts

Though, most of the Win32 thread functions have an analog in BeOS. Shouldn't be too hard to do anyway.