www.digitalmars.com         C & C++   DMDScript  

D.gnu - Linker problems with arm-wince, need help/info

reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Whenever I try to compile stuff with the arm-wince-pe-gdc compiler I'm 
working on, it gives me this kind of error message:

/tmp/ccCUG0Nj.o(.text+0x44):main.d: undefined reference to 
`_D3std4file5writeFAaAvZv'
/tmp/ccCUG0Nj.o(.text+0x8c):main.d: undefined reference to `_Dmodule_ref'
/tmp/ccCUG0Nj.o(.data+0x40):main.d: undefined reference to 
`_ModuleInfo_3std4file'
/usr/local/arm-wince-pe/EntryPoint/Console/crt0.o(.text+0x2c): undefined 
reference to `main'
collect2: ld returned 1 exit status

I'm pretty sure it is linking in gphobos.  I've even tried explicitly 
linking to gphobos, and I get exactly the same problems.  Lemme guess, 
the same startfile (crt0.o) that worked for C plus plus, won't work for 
D?  If that's the case, I'd like to know what D needs in a startfile and 
where I can go to learn how to write startfiles.

Otherwise, I'm fairly clueless.  I looked for those symbols in gphobos 
with a hex editor and found them.  I'm not sure what that means though 
as I don't understand the guts of the linking process.  My startfile 
hunch aside, anyone know what these errors might be about?
Jun 08 2006
parent reply David Friedman <dvdfrdmn users.ess-eff.net> writes:
Chad J wrote:

 Whenever I try to compile stuff with the arm-wince-pe-gdc compiler I'm 
 working on, it gives me this kind of error message:
 
 /tmp/ccCUG0Nj.o(.text+0x44):main.d: undefined reference to 
 `_D3std4file5writeFAaAvZv'
 /tmp/ccCUG0Nj.o(.text+0x8c):main.d: undefined reference to `_Dmodule_ref'
 /tmp/ccCUG0Nj.o(.data+0x40):main.d: undefined reference to 
 `_ModuleInfo_3std4file'
 /usr/local/arm-wince-pe/EntryPoint/Console/crt0.o(.text+0x2c): undefined 
 reference to `main'
 collect2: ld returned 1 exit status
 
 I'm pretty sure it is linking in gphobos.  I've even tried explicitly 
 linking to gphobos, and I get exactly the same problems.  Lemme guess, 
 the same startfile (crt0.o) that worked for C plus plus, won't work for 
 D?  If that's the case, I'd like to know what D needs in a startfile and 
 where I can go to learn how to write startfiles.
 
 Otherwise, I'm fairly clueless.  I looked for those symbols in gphobos 
 with a hex editor and found them.  I'm not sure what that means though 
 as I don't understand the guts of the linking process.  My startfile 
 hunch aside, anyone know what these errors might be about?


Two things to check:

What is the order of libraries / objects on the linker command line? 
(Use gdc -v ...)

Are the symbols actually defined in gphobos?  Use nm libgphobos.a to see 
if the names are actually definitions.

David
Jun 09 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
David Friedman wrote:

 
 Two things to check:
 
 What is the order of libraries / objects on the linker command line? 
 (Use gdc -v ...)
 
 Are the symbols actually defined in gphobos?  Use nm libgphobos.a to see 
 if the names are actually definitions.
 
 David


OK here is what I get when using the -v option:

Reading specs from 
/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-wince-pe/lib/specs
Reading specs from 
/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-wince-pe/lib/libgphobos.spec
rename spec lib to liborig
Target: arm-wince-pe
Configured with: /root/gcc/gdc-4.0.3/configure 
--prefix=/usr/local/arm-wince-pe--disable-nls --disable-unix 
--enable-multilib=no --enable-languages=c,d,c++ 
--with-build-time-tools=/usr/local/arm-wince-pe/bin 
--with-as=/usr/local/arm-wince-pe/bin/arm-wince-pe-as 
--with-ld=/usr/local/arm-wince-pe/bin/arm-wince-pe-ld 
--with-sysroot=/usr/local/arm-wince-pe 
--enable-phobos-config-dir=/usr/local/arm-wince-pe/phobos-config 
--target=arm-wince-pe
Thread model: single
gcc version 4.0.3 (gdc 0.18, using dmd 0.149)
  /usr/local/arm-wince-pe/libexec/gcc/arm-wince-pe/4.0.3/cc1d main.d 
-quiet -dumpbase main.d -auxbase main -version -fno-leading-underscore 
-o /tmp/ccuAOxMx.s
GNU D version 4.0.3 (gdc 0.18, using dmd 0.149) (arm-wince-pe)
         compiled by GNU C version 3.3.5 (Debian 1:3.3.5-13).
GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64492
  /usr/local/arm-wince-pe/bin/arm-wince-pe-as -o /tmp/ccAPqn32.o 
/tmp/ccuAOxMx.s
  /usr/local/arm-wince-pe/libexec/gcc/arm-wince-pe/4.0.3/collect2 -X 
-odtest.execrt0.o -L/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3 
-L/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../..
../arm-wince-pe/lib 
-L/usr/local/arm-wince-pe/lib -L/usr/local/arm-wince-pe/usr/lib 
/tmp/ccAPqn32.o -lgphobos -lm -lm-lcdll -lcdllimp -lcoredll


I searched in the result of nm libgphobos.a, and I found the missing 
symbols there.  Not sure how to read it though, and from what I can make 
of the binutils documentation on it I'll probably need to learn more 
about linking to understand it.  Anyhow, you should be able to find it 
at this link http://s17.quicksharing.com/v/8488120/1nm.txt.html (it was 
too big to fit on the ng).
Jun 12 2006
parent reply David Friedman <dvdfrdmn users.ess-eff.net> writes:
Chad J wrote:

 David Friedman wrote:
 

 Two things to check:

 What is the order of libraries / objects on the linker command line? 
 (Use gdc -v ...)

 Are the symbols actually defined in gphobos?  Use nm libgphobos.a to 
 see if the names are actually definitions.

 David


 
 
 OK here is what I get when using the -v option:
 
 Reading specs from 
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../ar
-wince-pe/lib/specs 
 
 Reading specs from 
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-wince-pe
lib/libgphobos.spec 
 
 rename spec lib to liborig
 Target: arm-wince-pe
 Configured with: /root/gcc/gdc-4.0.3/configure 
 --prefix=/usr/local/arm-wince-pe--disable-nls --disable-unix 
 --enable-multilib=no --enable-languages=c,d,c++ 
 --with-build-time-tools=/usr/local/arm-wince-pe/bin 
 --with-as=/usr/local/arm-wince-pe/bin/arm-wince-pe-as 
 --with-ld=/usr/local/arm-wince-pe/bin/arm-wince-pe-ld 
 --with-sysroot=/usr/local/arm-wince-pe 
 --enable-phobos-config-dir=/usr/local/arm-wince-pe/phobos-config 
 --target=arm-wince-pe
 Thread model: single
 gcc version 4.0.3 (gdc 0.18, using dmd 0.149)
  /usr/local/arm-wince-pe/libexec/gcc/arm-wince-pe/4.0.3/cc1d main.d 
 -quiet -dumpbase main.d -auxbase main -version -fno-leading-underscore 
 -o /tmp/ccuAOxMx.s
 GNU D version 4.0.3 (gdc 0.18, using dmd 0.149) (arm-wince-pe)
         compiled by GNU C version 3.3.5 (Debian 1:3.3.5-13).
 GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64492
  /usr/local/arm-wince-pe/bin/arm-wince-pe-as -o /tmp/ccAPqn32.o 
 /tmp/ccuAOxMx.s
  /usr/local/arm-wince-pe/libexec/gcc/arm-wince-pe/4.0.3/collect2 -X 
 -odtest.execrt0.o -L/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3 
 -L/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../..
../arm-wince-pe/lib 
 -L/usr/local/arm-wince-pe/lib -L/usr/local/arm-wince-pe/usr/lib 
 /tmp/ccAPqn32.o -lgphobos -lm -lm-lcdll -lcdllimp -lcoredll
 
 
 I searched in the result of nm libgphobos.a, and I found the missing 
 symbols there.  Not sure how to read it though, and from what I can make 
 of the binutils documentation on it I'll probably need to learn more 
 about linking to understand it.  Anyhow, you should be able to find it 
 at this link http://s17.quicksharing.com/v/8488120/1nm.txt.html (it was 
 too big to fit on the ng).


Something I noticed in the original message:

/usr/local/arm-wince-pe/EntryPoint/Console/crt0.o(.text+0x2c): undefined 
reference to `main'

Looking at the nm output, all global symbols a prefixed with an 
underscore.  It looks like the main in crt0.o doesn't have an underscore 
(I don't think GNU ld removes prefixes for error messages.)  That might 
be the problem.  Does the gcc built along with gdc have the same 
problem?  Where does EntryPoint/Console/crt0.o come from?

David
Jun 13 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
David Friedman wrote:

 
 Something I noticed in the original message:
 
 /usr/local/arm-wince-pe/EntryPoint/Console/crt0.o(.text+0x2c): undefined 
 reference to `main'
 
 Looking at the nm output, all global symbols a prefixed with an 
 underscore.  It looks like the main in crt0.o doesn't have an underscore 
 (I don't think GNU ld removes prefixes for error messages.)  That might 
 be the problem.  Does the gcc built along with gdc have the same 
 problem?  Where does EntryPoint/Console/crt0.o come from?
 
 David


It works for C and C plus plus, both for console apps and windows GUI 
apps.  Compiles without problems and runs correctly too, not sure about 
anything more advanced then that (like exception handling).  I should 
mention there is also an EntryPoint/Windows/crt0.o.  I wrote a dummy 
linker that tries to determine which kind of program you are writing, 
and calls the real linker with the appropriate startfile.  The 
startfiles themselves originate from some of the files Mamaich used in 
his arm-wince-pe C plus plus cross compiler.  The original crt0 
startfiles that came with the files I was using did not work - the 
compiler couldn't find the entry symbol on them.  To fix this I found 
the original assembly of crt0.o, crt0.S, and replaced the symbol I 
thought to be the intended entry point with the one that the 
compiler/linker was looking for, then assembled it.  I've attached what 
I believe to be the original crt0.S before my modifications, but it's 
been a while since I messed with it so I can't be sure if it's the right 
one.

I've noticed that in a x86-linux install of GDC, there are a number of 
startfile looking object files in lib/gcc/i686-pc-linux-gnu/4.0.3 - 
crtbegin.o, crtbeginS.o, crtbeginT.o, crtend.o, and crtendS.o.  There's 
about 8.5 KB of important looking code there, whereas the cross compiler 
I've made has just the one 676 KB startfile.  I'm wondering why those 
other files didn't build with this cross compiler, and if their lack 
might be the problem.
Jun 13 2006
parent reply pedro alves <pedro.alves domatica.pt> writes:
Hi Chad and all,

Chad J wrote:

 David Friedman wrote:

 Something I noticed in the original message:

 /usr/local/arm-wince-pe/EntryPoint/Console/crt0.o(.text+0x2c):
 undefined reference to `main'

 Looking at the nm output, all global symbols a prefixed with an
 underscore.  It looks like the main in crt0.o doesn't have an
 underscore (I don't think GNU ld removes prefixes for error
 messages.)  That might be the problem.  Does the gcc built along with
 gdc have the same problem?  Where does EntryPoint/Console/crt0.o come
 from?

 David


 It works for C and C plus plus, both for console apps and windows GUI
 apps.  Compiles without problems and runs correctly too, not sure about
 anything more advanced then that (like exception handling).  I should
 mention there is also an EntryPoint/Windows/crt0.o.  I wrote a dummy
 linker that tries to determine which kind of program you are writing,
 and calls the real linker with the appropriate startfile.  The
 startfiles themselves originate from some of the files Mamaich used in
 his arm-wince-pe C plus plus cross compiler.


Yes, it seems that wrong target underscoring is the problem here. I have
seen this problem too when moving Mamaich's toolchain into gcc4.

You should check cegcc's (http://cegcc.berlios.de) start files. They are
similar, but not the same.

There are other problems that I fixed for c++ and for binutils related
to underscoring. I have fixes (some are already in binutils mainline),
to enable the generation of correct dlls.

You will find patches for that at cegcc's file section.
I don't know if d is debuggable with gdb, but I have also improved on
gdb for
arm-wince-pe. For that you will need to get gdb from cegcc's svn.

That being said, are can try adding a
-fno-leading-underscore to TARGET_LIBGCC2_CFLAGS in
gcc/config/arm/t-wince-pe

Cheers,
Pedro Alves
Jun 14 2006
next sibling parent Chad J <gamerChad _spamIsBad_gmail.com> writes:
pedro alves wrote:

 
 Yes, it seems that wrong target underscoring is the problem here. I have
 seen this problem too when moving Mamaich's toolchain into gcc4.
 
 You should check cegcc's (http://cegcc.berlios.de) start files. They are
 similar, but not the same.
 
 There are other problems that I fixed for c++ and for binutils related
 to underscoring. I have fixes (some are already in binutils mainline),
 to enable the generation of correct dlls.
 
 You will find patches for that at cegcc's file section.
 I don't know if d is debuggable with gdb, but I have also improved on
 gdb for
 arm-wince-pe. For that you will need to get gdb from cegcc's svn.
 
 That being said, are can try adding a
 -fno-leading-underscore to TARGET_LIBGCC2_CFLAGS in
 gcc/config/arm/t-wince-pe
 
 Cheers,
 Pedro Alves


I will try out using cegcc on this as soon as I get the chance.  It 
seems very cool.  I wish I had seen cegcc when I had started on this 
project :)
Jun 14 2006
prev sibling parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
pedro alves wrote:

 Hi Chad and all,
 
 Yes, it seems that wrong target underscoring is the problem here. I have
 seen this problem too when moving Mamaich's toolchain into gcc4.
 
 You should check cegcc's (http://cegcc.berlios.de) start files. They are
 similar, but not the same.
 
 There are other problems that I fixed for c++ and for binutils related
 to underscoring. I have fixes (some are already in binutils mainline),
 to enable the generation of correct dlls.
 
 You will find patches for that at cegcc's file section.
 I don't know if d is debuggable with gdb, but I have also improved on
 gdb for
 arm-wince-pe. For that you will need to get gdb from cegcc's svn.
 
 That being said, are can try adding a
 -fno-leading-underscore to TARGET_LIBGCC2_CFLAGS in
 gcc/config/arm/t-wince-pe
 
 Cheers,
 Pedro Alves


Note that I cannot use cegcc's gcc, since it is based off of 4.1.x gcc 
which is not compatible with gdc.

Also, -fno-leading-underscore is used by the specfile I am using in this 
compiler.  So it's been in use, how much so I am unsure of though.  In 
fact, I'll attach my specfile since that may help things.

First thing I did was download and install the cegcc binutils.  I got 
them from the file downloads on the berliOS site.  I then 
recompiled/reinstalled arm-wince-pe-gdc with the new binutils, and with 
-fno-leading-underscore inserted in TARGET_LIBGCC2_CFLAGS.
Using my old crt0.o file in this configuration led to the same old errors.
Using a crt0.o I grabbed off of the cegcc-0.0.2 cygwin binaries yielded 
these errors:

/tmp/cc7BG4tk.o:main.d:(.text+0x44): undefined reference to 
`_D3std4file5writeFAaAvZv'
/tmp/cc7BG4tk.o:main.d:(.text+0x8c): undefined reference to `_Dmodule_ref'
/tmp/cc7BG4tk.o:main.d:(.data+0x40): undefined reference to 
`_ModuleInfo_3std4file'
/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-wince-pe/lib/crt0.o:/cygdrive/d/gcc/gcc-trunk/newlib/libc/
ys/wince/crt0.S:43: 
undefined reference to `main2'

Then I noticed where the crt0.S file that made that crt0.o file came 
from, and I found that in the cegcc-0.0.3 sources and tried to assemble 
that, but the assembler gave me an error:

crt0.S: Assembler messages:
crt0.S:24: Error: bad instruction `func_start __EH_HANDLER__'

hmmm, so I changed that line to what it was in my startfile.  Then it 
assembled fine, but when I used this new startfile I get the following 
errors:

/tmp/ccCPaYXV.o:main.d:(.text+0x44): undefined reference to 
`_D3std4file5writeFAaAvZv'
/tmp/ccCPaYXV.o:main.d:(.text+0x8c): undefined reference to `_Dmodule_ref'
/tmp/ccCPaYXV.o:main.d:(.data+0x40): undefined reference to 
`_ModuleInfo_3std4file'
/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
undefined reference to `__set_runtime_thread_mode'
/usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
undefined reference to `main'

Since the spec file seems to override the builtin stuff, I tried 
removing -fno-leading-underscore from my specfile to see what would 
happen, and it gives many more errors on compilation.  I'm guessing the 
-fno-leading-underscore is fairly essential, or the resultant programs 
wouldn't be able to do essential things like talk to the WinCE OS/API, 
whose name manglings would have different underscoring.

Concerning a somewhat unrelated problem, I wonder if there is a way to 
make something happen without an external specfile, that is, build it 
into the compiler:  I want it to include fixincl.h, but only for C and C 
plus plus compilation.  I tried putting this in TARGET_LIBGCC2_CFLAGS, 
but that messes up assembly :)
The reason I ask is this would save a nasty hack I have to do.  As it 
is, the make of gcc/gdc will fail when it gets to phobos because it 
tries to compile C files for arm-wince, but since it lacks the correct 
include info it fails.  So I made a dummy compiler that calls the real 
compiler and tells it to include fixincl.h.  Once make fails at phobos, 
I have to repeatedly replace xgcc with my own xgcc until the thing works 
(some motor skills and not-too-fast computer required!).
Jun 17 2006
parent reply pedro alves <pedro.alves domatica.pt> writes:
Hi,

Chad J wrote:

 pedro alves wrote:

 That being said, are can try adding a
 -fno-leading-underscore to TARGET_LIBGCC2_CFLAGS in
 gcc/config/arm/t-wince-pe


 Note that I cannot use cegcc's gcc, since it is based off of 4.1.x gcc 
 which is not compatible with gdc.


Too bad...
It should be possible to apply cegcc's patches to gcc 4.0 though. I 
started development against 4.0 and when I moved to 4.1 almost nothing 
changed.
I guess at some point you will want to move to 4.1 or 4.2, though.


 Also, -fno-leading-underscore is used by the specfile I am using in 
 this compiler.  So it's been in use, how much so I am unsure of 
 though.  In fact, I'll attach my specfile since that may help things.

 First thing I did was download and install the cegcc binutils.  I got 
 them from the file downloads on the berliOS site.  I then 
 recompiled/reinstalled arm-wince-pe-gdc with the new binutils, and 
 with -fno-leading-underscore inserted in TARGET_LIBGCC2_CFLAGS.
 Using my old crt0.o file in this configuration led to the same old 
 errors.
 Using a crt0.o I grabbed off of the cegcc-0.0.2 cygwin binaries 
 yielded these errors:

 /tmp/cc7BG4tk.o:main.d:(.text+0x44): undefined reference to 
 `_D3std4file5writeFAaAvZv'
 /tmp/cc7BG4tk.o:main.d:(.text+0x8c): undefined reference to 
 `_Dmodule_ref'
 /tmp/cc7BG4tk.o:main.d:(.data+0x40): undefined reference to 
 `_ModuleInfo_3std4file'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-wince-pe/lib/crt0.o:/cygdrive/d/gcc/gcc-trunk/newlib/libc/
ys/wince/crt0.S:43: 
 undefined reference to `main2'


Old stuff. :) There was once a -Dmain=main2. It is now gone in recent 
versions.


 Then I noticed where the crt0.S file that made that crt0.o file came 
 from, and I found that in the cegcc-0.0.3 sources and tried to 
 assemble that, but the assembler gave me an error:

 crt0.S: Assembler messages:
 crt0.S:24: Error: bad instruction `func_start __EH_HANDLER__'


The 'S' (uppercase) suffix means the file should be preprocessed before 
being assembled. func_start is a macro.


 hmmm, so I changed that line to what it was in my startfile.  Then it 
 assembled fine, but when I used this new startfile I get the following 
 errors:

 /tmp/ccCPaYXV.o:main.d:(.text+0x44): undefined reference to 
 `_D3std4file5writeFAaAvZv'
 /tmp/ccCPaYXV.o:main.d:(.text+0x8c): undefined reference to 
 `_Dmodule_ref'
 /tmp/ccCPaYXV.o:main.d:(.data+0x40): undefined reference to 
 `_ModuleInfo_3std4file'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `__set_runtime_thread_mode'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `main'



 Since the spec file seems to override the builtin stuff, I tried 
 removing -fno-leading-underscore from my specfile to see what would 
 happen, and it gives many more errors on compilation.  I'm guessing 
 the -fno-leading-underscore is fairly essential, or the resultant 
 programs wouldn't be able to do essential things like talk to the 
 WinCE OS/API, whose name manglings would have different underscoring.


"on compilation"? You mean on linking, right?

Lets ignore the __set_runtime_thread_mode, since you are not using a 
recent cegcc runtime, where that function lives.

Ok. looks like those D function calls are somehow being emitted with an 
underscore.
Who inserts the unscore in _D3std4file5writeFAaAvZv? Is it the D 
mangling that requires it?
Or could it be that the -fno-leading-underscore is being ignored by the 
D frontend?

Are you really sure these functions are defined?
Isn't your 'main' being D mangled? I don't almost nothing D, just an 
observer, but, isn't there an extern "C" equivalent required
around your main function? I guess there will be an extern "C" main that 
initializes  phobos and then calls a _Dmain, or whatever.
Where is this extern "C" main?

In recent cegcc, there is a default main in -lc that ld sucks in if the 
the app doesn't define one. In Mamaich's toolchain, it is the other way 
around, a default WinMain would call main.
I don't get why that isn't being found by ld. Did you build that cdllimp 
with gcc4, or is it exactly the same from Mamaich? That would be 
problematic, since
it was built against gcc 3.x.


 Concerning a somewhat unrelated problem, I wonder if there is a way to 
 make something happen without an external specfile, that is, build it 
 into the compiler:  I want it to include fixincl.h, but only for C and 
 C plus plus compilation.  I tried putting this in 
 TARGET_LIBGCC2_CFLAGS, but that messes up assembly :)
 The reason I ask is this would save a nasty hack I have to do.  As it 
 is, the make of gcc/gdc will fail when it gets to phobos because it 
 tries to compile C files for arm-wince, but since it lacks the correct 
 include info it fails.  So I made a dummy compiler that calls the real 
 compiler and tells it to include fixincl.h.  Once make fails at 
 phobos, I have to repeatedly replace xgcc with my own xgcc until the 
 thing works (some motor skills and not-too-fast computer required!).
   


What are the contents of this fixincl.h? Doesn't phobos have something 
like a config.h where you can make this changes?

To be able to include wince sdk files with gcc I use a scheme of:
--- windows.h

#include "fixincl.h"
#include_next <windows.h>

----

I guess the fixincl.h name in this case is just a coincidence :)

Cheers,
Pedro Alves
Jun 18 2006
parent reply Chad J <""gamerChad\" spamIsBad gmail.com"> writes:
pedro alves wrote:

 Then I noticed where the crt0.S file that made that crt0.o file came 
 from, and I found that in the cegcc-0.0.3 sources and tried to 
 assemble that, but the assembler gave me an error:

 crt0.S: Assembler messages:
 crt0.S:24: Error: bad instruction `func_start __EH_HANDLER__'


 The 'S' (uppercase) suffix means the file should be preprocessed before 
 being assembled. func_start is a macro.


Ah, good to know.


 

 hmmm, so I changed that line to what it was in my startfile.  Then it 
 assembled fine, but when I used this new startfile I get the following 
 errors:

 /tmp/ccCPaYXV.o:main.d:(.text+0x44): undefined reference to 
 `_D3std4file5writeFAaAvZv'
 /tmp/ccCPaYXV.o:main.d:(.text+0x8c): undefined reference to 
 `_Dmodule_ref'
 /tmp/ccCPaYXV.o:main.d:(.data+0x40): undefined reference to 
 `_ModuleInfo_3std4file'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `__set_runtime_thread_mode'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `main'


 

 Since the spec file seems to override the builtin stuff, I tried 
 removing -fno-leading-underscore from my specfile to see what would 
 happen, and it gives many more errors on compilation.  I'm guessing 
 the -fno-leading-underscore is fairly essential, or the resultant 
 programs wouldn't be able to do essential things like talk to the 
 WinCE OS/API, whose name manglings would have different underscoring.


 "on compilation"? You mean on linking, right?


Right.


 
 Ok. looks like those D function calls are somehow being emitted with an 
 underscore.
 Who inserts the unscore in _D3std4file5writeFAaAvZv? Is it the D 
 mangling that requires it?
 Or could it be that the -fno-leading-underscore is being ignored by the 
 D frontend?
 
 Are you really sure these functions are defined?


In an earlier post David asked me to run nm libgphobos.a, and I gave a 
link to that result.  I'm not sure how to read it so you can check for 
yourself.
Anyhow least a couple of the D ones seem to be defined in GPhobos.  I 
wonder if they are supposed to be found in the startfile though.  The 
leading underscore seems more likely.  I wonder though, was linking 
required to archive gphobos, or is that linking done when the executable 
is generated?  I ask because that would explain why it was able to 
"link" gphobos, but can not handle the D function calls in my simple 
program.


 Isn't your 'main' being D mangled? I don't almost nothing D, just an 
 observer, but, isn't there an extern "C" equivalent required
 around your main function? I guess there will be an extern "C" main that 
 initializes  phobos and then calls a _Dmain, or whatever.
 Where is this extern "C" main?


Putting extern(C) infront of main is not required.  I think there should 
be a second main though, with C linkage, that will do all of the setup 
for D, then call the main with D linkage.  I could be wrong though.  At 
any rate, I think there is a lot of startup code that should be there 
but isn't.  Stuff that would call all of the module ctors.


 
 In recent cegcc, there is a default main in -lc that ld sucks in if the 
 the app doesn't define one. In Mamaich's toolchain, it is the other way 
 around, a default WinMain would call main.
 I don't get why that isn't being found by ld. Did you build that cdllimp 
 with gcc4, or is it exactly the same from Mamaich? That would be 
 problematic, since
 it was built against gcc 3.x.


I am using the one from Mamaich.  I guess this means I need to rebuild 
newlib?


 

 Concerning a somewhat unrelated problem, I wonder if there is a way to 
 make something happen without an external specfile, that is, build it 
 into the compiler:  I want it to include fixincl.h, but only for C and 
 C plus plus compilation.  I tried putting this in 
 TARGET_LIBGCC2_CFLAGS, but that messes up assembly :)
 The reason I ask is this would save a nasty hack I have to do.  As it 
 is, the make of gcc/gdc will fail when it gets to phobos because it 
 tries to compile C files for arm-wince, but since it lacks the correct 
 include info it fails.  So I made a dummy compiler that calls the real 
 compiler and tells it to include fixincl.h.  Once make fails at 
 phobos, I have to repeatedly replace xgcc with my own xgcc until the 
 thing works (some motor skills and not-too-fast computer required!).
   


 What are the contents of this fixincl.h? Doesn't phobos have something 
 like a config.h where you can make this changes?
 
 To be able to include wince sdk files with gcc I use a scheme of:
 --- windows.h
 
 #include "fixincl.h"
 #include_next <windows.h>
 
 ----
 
 I guess the fixincl.h name in this case is just a coincidence :)


Probably just a coincidence, though I wouldn't be suprised if they are 
the same file.  I got my fixincl.h from Mamaich, it seems to just 
#define away a lot of the microsoft compiler features.  What you posted 
here looks like a much cleaner solution than making sure the include is 
passed to the preprocessor.


 
 Cheers,
 Pedro Alves
Jun 18 2006
parent reply pedro alves <pedro.alves domatica.pt> writes:
Chad J > wrote:

 hmmm, so I changed that line to what it was in my startfile.  Then 
 it assembled fine, but when I used this new startfile I get the 
 following errors:

 /tmp/ccCPaYXV.o:main.d:(.text+0x44): undefined reference to 
 `_D3std4file5writeFAaAvZv'
 /tmp/ccCPaYXV.o:main.d:(.text+0x8c): undefined reference to 
 `_Dmodule_ref'
 /tmp/ccCPaYXV.o:main.d:(.data+0x40): undefined reference to 
 `_ModuleInfo_3std4file'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `__set_runtime_thread_mode'
 /usr/local/arm-wince-pe/lib/gcc/arm-wince-pe/4.0.3/../../../../arm-w
nce-pe/lib/crt0.o:: 
 undefined reference to `main'





 Ok. looks like those D function calls are somehow being emitted with 
 an underscore.
 Who inserts the unscore in _D3std4file5writeFAaAvZv? Is it the D 
 mangling that requires it?
 Or could it be that the -fno-leading-underscore is being ignored by 
 the D frontend?

 Are you really sure these functions are defined?


 In an earlier post David asked me to run nm libgphobos.a, and I gave a 
 link to that result.  I'm not sure how to read it so you can check for 
 yourself.
 Anyhow least a couple of the D ones seem to be defined in GPhobos.  I 
 wonder if they are supposed to be found in the startfile though.  The 
 leading underscore seems more likely.  I wonder though, was linking 
 required to archive gphobos, or is that linking done when the 
 executable is generated?  I ask because that would explain why it was 
 able to "link" gphobos, but can not handle the D function calls in my 
 simple program.


Sorry, missed that link. It would be better to run arm-wince-pe-nm -A, 
as that would show where the functions are defined.
For static libs there can be undefined symbols. For shared libs, depends 
on the OS. In Windows dlls need full closure.
That's why you only see unresolved symbols when you compile an 
executable, as those also need full closure.


 Isn't your 'main' being D mangled? I don't almost nothing D, just an 
 observer, but, isn't there an extern "C" equivalent required
 around your main function? I guess there will be an extern "C" main 
 that initializes  phobos and then calls a _Dmain, or whatever.
 Where is this extern "C" main?


 Putting extern(C) infront of main is not required.  I think there 
 should be a second main though, with C linkage, that will do all of 
 the setup for D, then call the main with D linkage.  I could be wrong 
 though.  At any rate, I think there is a lot of startup code that 
 should be there but isn't.  Stuff that would call all of the module 
 ctors.


That's what I meant :) An extern (C) main in phobos that does all the 
setup and then calls a _Dmain. I even guessed the name right :)

$ grep main 1nm.txt 
00000024 R __D3gcc6config21dirent_remaining_sizek
00000a38 T __D3std4math9remainderFeeZe
         U _remainder
dgccmain2.o:
00000094 T __d_run_main
00000000 t __d_run_main2goFZv
rundmain.o:
         U __Dmain            <------- probably the D main in app code.
00000000 T __d_run_Dmain
         U __d_run_main
cmain.o:
         U __Dmain
         U ___gccmain
         U __d_run_main
00000000 T _main           <------- look here, it is underscored :)

So main is being underscored. Take a look at where that _main (should be 
main in source form) is defined. I would guess,
that it is implemented in D with extern (C). I think the D frontend will 
need to be extended to support -fno-leading-underscore, at least for
extern (C) function calls/declarations, but I guess supporting it for 
*all* function decls/calls will be easier, probably there will be a 
single function that
handles the mangling. Look for that.
As a quick hack, you can change the start file from where it reads 
".word main " to ".word _main". But, that will be delaying the right 
solution,
because all the functions in cdll, and cdllimp, for mamaich's toolchain, 
and in cegcc.dll for cegcc toolchain, are *not* underscored. The same
for MS's SDK.

Hummm,

$ grep _D3std4file5writeFAaAvZv 1nm.txt
00001010 T __D3std4file5writeFAaAvZv

Maybe the functions definitions are being emitted with underscore, but 
function calls are being emitted *without* underscore?
That would explain it all.


 In recent cegcc, there is a default main in -lc that ld sucks in if 
 the the app doesn't define one. In Mamaich's toolchain, it is the 
 other way around, a default WinMain would call main.
 I don't get why that isn't being found by ld. Did you build that 
 cdllimp with gcc4, or is it exactly the same from Mamaich? That would 
 be problematic, since
 it was built against gcc 3.x.


 I am using the one from Mamaich.  I guess this means I need to rebuild 
 newlib?


To be safe, I would say yes. Really, cegcc should be your friend here :)
<closing my own eyes/ears>
But, if I were you, I would delay that as much possible. If it works, 
don't change it :)
</closing my own eyes/ears>


 I guess the fixincl.h name in this case is just a coincidence :)


 Probably just a coincidence, though I wouldn't be suprised if they are 
 the same file.  I got my fixincl.h from Mamaich, it seems to just 
 #define away a lot of the microsoft compiler features.  What you 
 posted here looks like a much cleaner solution than making sure the 
 include is passed to the preprocessor.


Ah, same file. Although cegcc's is much updated. I recomend atleast 
using at least this file from cegcc.


Cheers,
Pedro Alves
Jun 18 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
pedro alves wrote:

 Sorry, missed that link. It would be better to run arm-wince-pe-nm -A, 
 as that would show where the functions are defined.
 For static libs there can be undefined symbols. For shared libs, depends 
 on the OS. In Windows dlls need full closure.
 That's why you only see unresolved symbols when you compile an 
 executable, as those also need full closure.


I ran arm-wince-pe-nm -A ..., and I put the result (nmDashA.gz) on this 
file sharing website:

http://www.4shared.com/dir/510508/1b9c639d/shared.html

(this one is more direct if it works)
http://www.4shared.com/file/2127855/9332c700


 That's what I meant :) An extern (C) main in phobos that does all the 
 setup and then calls a _Dmain. I even guessed the name right :)
 
 $ grep main 1nm.txt 00000024 R __D3gcc6config21dirent_remaining_sizek
 00000a38 T __D3std4math9remainderFeeZe
         U _remainder
 dgccmain2.o:
 00000094 T __d_run_main
 00000000 t __d_run_main2goFZv
 rundmain.o:
         U __Dmain            <------- probably the D main in app code.
 00000000 T __d_run_Dmain
         U __d_run_main
 cmain.o:
         U __Dmain
         U ___gccmain
         U __d_run_main
 00000000 T _main           <------- look here, it is underscored :)
 
 So main is being underscored. Take a look at where that _main (should be 
 main in source form) is defined. I would guess,
 that it is implemented in D with extern (C). I think the D frontend will 
 need to be extended to support -fno-leading-underscore, at least for
 extern (C) function calls/declarations, but I guess supporting it for 
 *all* function decls/calls will be easier, probably there will be a 
 single function that
 handles the mangling. Look for that.
 As a quick hack, you can change the start file from where it reads 
 ".word main " to ".word _main". But, that will be delaying the right 
 solution,
 because all the functions in cdll, and cdllimp, for mamaich's toolchain, 
 and in cegcc.dll for cegcc toolchain, are *not* underscored. The same
 for MS's SDK.


I tried that hack.  I creates a whole new slew of errors.  I put as many 
of them as I could into the file attached to this post.  There were too 
many to fit in the console, and I wasn't able to output it to a file. 
Looks to me like it is using function calls with underscores when those 
libs do not use the underscores - the kind of trouble you seemed to 
imply about not fixing the frontend.

I tried looking through the frontend.  There was a file dedicated to 
mangling (gcc/d/dmd/mangle.c).  I still can't figure out where the 
underscoring is handled, at least for C linkage.  I tried one obvious 
looking line change, but it didn't fix the C linkage at all.  I feel 
kinda helpless in the frontend, as I do not know much about compiler 
internals, much less GCC internals.  Maybe David can help here? Please?

I also don't understand why this would have any effect on D linkage like 
_D3std4file5writeFAaAvZv, at least that seems to be D linkage since it 
has the module name and the trailing type info.  With respect to 
underscoring, does the linker handle symbols any differently than say, 
an x86 linker?
Jun 19 2006
parent reply Pedro Alves <pedro.alves domatica.pt> writes:
Chad J wrote:


 pedro alves wrote:


 That's what I meant :) An extern (C) main in phobos that does all the 
 setup and then calls a _Dmain. I even guessed the name right :)

 $ grep main 1nm.txt 00000024 R __D3gcc6config21dirent_remaining_sizek
 00000a38 T __D3std4math9remainderFeeZe
         U _remainder
 dgccmain2.o:
 00000094 T __d_run_main
 00000000 t __d_run_main2goFZv
 rundmain.o:
         U __Dmain            <------- probably the D main in app code.
 00000000 T __d_run_Dmain
         U __d_run_main
 cmain.o:
         U __Dmain
         U ___gccmain
         U __d_run_main
 00000000 T _main           <------- look here, it is underscored :)

 So main is being underscored. Take a look at where that _main (should 
 be main in source form) is defined. I would guess,
 that it is implemented in D with extern (C). I think the D frontend 
 will need to be extended to support -fno-leading-underscore, at least 
 for
 extern (C) function calls/declarations, but I guess supporting it for 
 *all* function decls/calls will be easier, probably there will be a 
 single function that
 handles the mangling. Look for that.


 I tried looking through the frontend.  There was a file dedicated to 
 mangling (gcc/d/dmd/mangle.c).  I still can't figure out where the 
 underscoring is handled, at least for C linkage.  I tried one obvious 
 looking line change, but it didn't fix the C linkage at all.  I feel 
 kinda helpless in the frontend, as I do not know much about compiler 
 internals, much less GCC internals.  Maybe David can help here? Please?


Try putting a breakpoint there and stepping until the underscore is 
prepended. I don't know much about these parts of gcc either.


 I also don't understand why this would have any effect on D linkage 
 like _D3std4file5writeFAaAvZv, at least that seems to be D linkage 
 since it has the module name and the trailing type info.  


Well, to the linker, it is just a symbol like all the others. The 
mangling is there to make the function name unique, so you can have 
overloading at the D level, but to the linker, it has
no difference to any other C function or ASM function. The thing is, the 
mangler converts (i'm guessing the name now) std.file.write(...) into 
_D3std4file5writeFAaAvZv, but somewhere
between that and the emitting to the .s file that gets passed to the 
assembler, an underscore is prepended to the symbol, turning it into 
__D3std4file5writeFAaAvZv.
Find the place where this underscore is added, and disabled it. That's 
the place the -fno-leading-underscore should be respected. You can also 
grep the gcc sources to see
where that switch is handled for c and c++, and do the same.


 With respect to underscoring, does the linker handle symbols any 
 differently than say, an x86 linker?


With respect to underscoring, yes, it accounts for the underscore when 
the target is underscored, and doesn't, when the target isn't. You can 
look at binutils/ld/pe-dll.c to see it in action.
I have some hacks in cegcc's version of binutils that are needed here. 
Grep for "pedro" there if you are curious :)

...

I looked at the attatchment you sent. Well, you definitily have an 
underscoring mismatch.

Another thing. If after you fix this underscoring business you stil get 
errors like:
/root/gcc/gdc-4.0.3/libphobos/std/typeinfo/ti_creal.d:31: variable 
'___gtdf2' can't be auto-imported. Please read the documentation for 
ld's --enable-auto-import for details.

You will need to use the --enable-runtime-pseudo-reloc linker switch, 
but that needs runtime support, that mamaich's toolchain doesn't have. 
Luckily, cegcc has it :)

Cheers,
Pedro Alves
Jun 20 2006
parent reply Pedro Alves <pedro.alves domatica.pt> writes:
One more thing.
There is usually a #define USER_LABEL_PREFIX "_" or #define USER_LABEL_PREFIX ""
in gcc/config/$arch/someheader.h. In cegcc it is defined as USER_LABEL_PREFIX
"".
Maybe that isn't being used in the D frontend and an '_' is preppended
unconditionally?


Pedro Alves wrote:


 Chad J wrote:


 pedro alves wrote:


 That's what I meant :) An extern (C) main in phobos that does all 
 the setup and then calls a _Dmain. I even guessed the name right :)

 $ grep main 1nm.txt 00000024 R __D3gcc6config21dirent_remaining_sizek
 00000a38 T __D3std4math9remainderFeeZe
         U _remainder
 dgccmain2.o:
 00000094 T __d_run_main
 00000000 t __d_run_main2goFZv
 rundmain.o:
         U __Dmain            <------- probably the D main in app code.
 00000000 T __d_run_Dmain
         U __d_run_main
 cmain.o:
         U __Dmain
         U ___gccmain
         U __d_run_main
 00000000 T _main           <------- look here, it is underscored :)

 So main is being underscored. Take a look at where that _main 
 (should be main in source form) is defined. I would guess,
 that it is implemented in D with extern (C). I think the D frontend 
 will need to be extended to support -fno-leading-underscore, at 
 least for
 extern (C) function calls/declarations, but I guess supporting it 
 for *all* function decls/calls will be easier, probably there will 
 be a single function that
 handles the mangling. Look for that.



 I tried looking through the frontend.  There was a file dedicated to 
 mangling (gcc/d/dmd/mangle.c).  I still can't figure out where the 
 underscoring is handled, at least for C linkage.  I tried one obvious 
 looking line change, but it didn't fix the C linkage at all.  I feel 
 kinda helpless in the frontend, as I do not know much about compiler 
 internals, much less GCC internals.  Maybe David can help here? Please?


 Try putting a breakpoint there and stepping until the underscore is 
 prepended. I don't know much about these parts of gcc either.


 I also don't understand why this would have any effect on D linkage 
 like _D3std4file5writeFAaAvZv, at least that seems to be D linkage 
 since it has the module name and the trailing type info.  



 Well, to the linker, it is just a symbol like all the others. The 
 mangling is there to make the function name unique, so you can have 
 overloading at the D level, but to the linker, it has
 no difference to any other C function or ASM function. The thing is, 
 the mangler converts (i'm guessing the name now) std.file.write(...) 
 into _D3std4file5writeFAaAvZv, but somewhere
 between that and the emitting to the .s file that gets passed to the 
 assembler, an underscore is prepended to the symbol, turning it into 
 __D3std4file5writeFAaAvZv.
 Find the place where this underscore is added, and disabled it. That's 
 the place the -fno-leading-underscore should be respected. You can 
 also grep the gcc sources to see
 where that switch is handled for c and c++, and do the same.


 With respect to underscoring, does the linker handle symbols any 
 differently than say, an x86 linker?



 With respect to underscoring, yes, it accounts for the underscore when 
 the target is underscored, and doesn't, when the target isn't. You can 
 look at binutils/ld/pe-dll.c to see it in action.
 I have some hacks in cegcc's version of binutils that are needed here. 
 Grep for "pedro" there if you are curious :)

 ...

 I looked at the attatchment you sent. Well, you definitily have an 
 underscoring mismatch.

 Another thing. If after you fix this underscoring business you stil 
 get errors like:
 /root/gcc/gdc-4.0.3/libphobos/std/typeinfo/ti_creal.d:31: variable 
 '___gtdf2' can't be auto-imported. Please read the documentation for 
 ld's --enable-auto-import for details.

 You will need to use the --enable-runtime-pseudo-reloc linker switch, 
 but that needs runtime support, that mamaich's toolchain doesn't have. 
 Luckily, cegcc has it :)

 Cheers,
 Pedro Alves
Jun 20 2006
parent reply Chad J <gamerChad _spamIsBad_gmail.com> writes:
Pedro Alves wrote:

 One more thing.
 There is usually a #define USER_LABEL_PREFIX "_" or #define 
 USER_LABEL_PREFIX ""
 in gcc/config/$arch/someheader.h. In cegcc it is defined as 
 USER_LABEL_PREFIX "".
 Maybe that isn't being used in the D frontend and an '_' is preppended 
 unconditionally?
 


This seems to have saved the day!

In gcc/config/arm/wince-pe.h I added this code:

#undef  LIB_SPEC
#define LIB_SPEC \
   { "%{staticlibs:-lgcc -lstdc++ -lsupc++ -lc -lm -lwinsock} 
%{!staticlibs:-lcdll -lcdllimp} -lcoredll" }

// solve underscoring problems when linking
#undef  USER_LABEL_PREFIX
#define USER_LABEL_PREFIX ""

The LIB_SPEC stuff makes it link to the newlib libraries and such 
without the need of an external specfile - this saves anyone who wants 
to build this from having to do a bunch of xgcc trickery to get the 
thing to eat a specfile.

Apparently I'm not out of the woods yet though.  There are unresolved 
references still.  The linker's error output is attached.  It seems to 
be all Phobos stuff - it's calling functions that I don't think exist on 
WinCE.  For some reason those functions must be defined in the headers 
while not actually being implemented.  These are things like 
GetCurrentDirectory, which shouldn't exist since WinCE doesn't have the 
concept of a current working dir (AFAIK).  If I'm wrong about this, do 
let me know before I get too far in extending parts of phobos.

I'm probably going to try cegcc newlib now.  Hopefully it can fill in 
some of those undefined references.

Thanks for the massive help Pedro!  Your intervention just saved me many 
hours of pain and frustration :)
Thank you too David, for the initial help and your work on GDC!
Jun 20 2006
parent reply pedro alves <pedro.alves domatica.pt> writes:
Chad J wrote:

 Pedro Alves wrote:

 One more thing.
 There is usually a #define USER_LABEL_PREFIX "_" or #define 
 USER_LABEL_PREFIX ""
 in gcc/config/$arch/someheader.h. In cegcc it is defined as 
 USER_LABEL_PREFIX "".
 Maybe that isn't being used in the D frontend and an '_' is preppended 
 unconditionally?


 
 This seems to have saved the day!
 
 In gcc/config/arm/wince-pe.h I added this code:
 
 #undef  LIB_SPEC
 #define LIB_SPEC \
   { "%{staticlibs:-lgcc -lstdc++ -lsupc++ -lc -lm -lwinsock} 
 %{!staticlibs:-lcdll -lcdllimp} -lcoredll" }
 
 // solve underscoring problems when linking
 #undef  USER_LABEL_PREFIX
 #define USER_LABEL_PREFIX ""
 
 The LIB_SPEC stuff makes it link to the newlib libraries and such 
 without the need of an external specfile - this saves anyone who wants 
 to build this from having to do a bunch of xgcc trickery to get the 
 thing to eat a specfile.
 
 Apparently I'm not out of the woods yet though.  There are unresolved 
 references still.  The linker's error output is attached.  It seems to 
 be all Phobos stuff - it's calling functions that I don't think exist on 
 WinCE.  For some reason those functions must be defined in the headers 
 while not actually being implemented.  These are things like 
 GetCurrentDirectory, which shouldn't exist since WinCE doesn't have the 
 concept of a current working dir (AFAIK).  If I'm wrong about this, do 
 let me know before I get too far in extending parts of phobos.
 
 I'm probably going to try cegcc newlib now.  Hopefully it can fill in 
 some of those undefined references.
 


Most of those undefined references you will be able to fix by switching 
from ascii to wide versions. Like CreateFileA -> CreateFileW, since 
wince is fully unicode (only).

And, the cegcc runtime has a notion of current directory. :)
I'm waiting for you at our mailing list ;)



 Thanks for the massive help Pedro!  Your intervention just saved me many 
 hours of pain and frustration :)
 Thank you too David, for the initial help and your work on GDC!
 
 


Thank you too, for making D possible in Windows CE. I will try D when
you have this working ;) I have been reading these newsgroups for ages,
but never really tried D.

Cheers,
Pedro Alves
Jun 20 2006
parent kris <foo bar.com> writes:
pedro alves wrote:

 Chad J wrote:
 

 Pedro Alves wrote:


 One more thing.
 There is usually a #define USER_LABEL_PREFIX "_" or #define 
 USER_LABEL_PREFIX ""
 in gcc/config/$arch/someheader.h. In cegcc it is defined as 
 USER_LABEL_PREFIX "".
 Maybe that isn't being used in the D frontend and an '_' is 
 preppended unconditionally?


 This seems to have saved the day!




[snip]

 Most of those undefined references you will be able to fix by switching 
 from ascii to wide versions. Like CreateFileA -> CreateFileW, since 
 wince is fully unicode (only).
 
 And, the cegcc runtime has a notion of current directory. :)
 I'm waiting for you at our mailing list ;)
 
 

 Thanks for the massive help Pedro!  Your intervention just saved me 
 many hours of pain and frustration :)
 Thank you too David, for the initial help and your work on GDC!


 
 Thank you too, for making D possible in Windows CE. I will try D when
 you have this working ;) 



Yeah ... me too!  Way to go, Chad :)
Jun 20 2006