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

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?

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

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

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!

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

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 :)