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