Linker problems with arm-wince, need help/info

[pedro alves]

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