Linker problems with arm-wince, need help/info
"gamerChad\" at spamIsBad gmail.com
Sun Jun 18 09:20:07 PDT 2006
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
>> /tmp/ccCPaYXV.o:main.d:(.text+0x44): undefined reference to
>> /tmp/ccCPaYXV.o:main.d:(.text+0x8c): undefined reference to
>> /tmp/ccCPaYXV.o:main.d:(.data+0x40): undefined reference to
>> undefined reference to `__set_runtime_thread_mode'
>> 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?
> Ok. looks like those D function calls are somehow being emitted with an
> 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
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
> 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
>> 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.
> Pedro Alves
More information about the D.gnu