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?

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

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

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

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

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.

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

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

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/sys/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-wince-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-wince-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!).

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/sys/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-wince-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-wince-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

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-wince-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-wince-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