Linker problems with arm-wince, need help/info

[Chad J]

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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: _main.gz
Type: application/octet-stream
Size: 4701 bytes
Desc: not available
Url : http://lists.puremagic.com/pipermail/d.gnu/attachments/20060620/7c58f871/attachment.obj