Linker problems with arm-wince, need help/info

[Chad J]

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