This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Kai: First off, thank you for your detailed and thoughtful response. We really do appreciate it.. > Quickly seen the FSF-gcc-3.x-sources DON'T support 'arm-wince-pe' at > all, only the 'generic' 'arm-pe' (do any embedded people use this?) > and the 'arm-epoc-pe'. There are other gcc-3.x sources with the > 'support' (at least it looks so...) though... So, what extra was > done in order to add the needed ARM/WinCE support ? This is not our understanding although we may be wrong. I was able to configure and build gcc with: % configure --target=arm-wince-pe --prefix=/usr/local/wince \ --enable-languages="c,c++" --with-headers=$basedir/wce300/inc \ --enable-multilib=no I have been using an unpatched, generic download of gcc-3.2 to do this. The only thing I've had to change is to make a few very minor alterations to libgcc2.c to deal with unresolved symbols at link time (for my test program!!). But on my RedHat 7.1 x86 machine, this configuration is accepted and I'm able to run the subsequent build of GCC to completion. Of course, it may be that the GCC configuration process accepts this target specification but does not produce anything useful from it. According to several people though, (e.g. Nick Clifton) this should be a (at least partially) supported configuration. I am using binutils-2.13, unpatched also, and configuring it with % configure --target=$target --prefix=/usr/local/wince >> Presumably the startup code or something else is wrong, but I am >> unsure what I should do next. > I have only the WinCE2.0 libs for MIPS and SH (and for the x86-emu), > and they had no separate 'startups' ('crt*.obj' or something), only > the libraries ('*.lib'). Does the WinCE3.0-stuff have some separate > startup files? Not that I can see. > Which startups and libs you linked against when creating the > executable? In the MIPS and SH cases the 'coredll.lib' and > 'corelibc.lib' seemed to be the basic C-libraries and one of > these had the C-startups included. To create an .exe with M$ Embedded Visual C++ compiler, the link for a (WORKING) simple "Hello World" type program looks as follows for WinCE 3.0: link /subsystem:windowsce,3.00 /entry:mainACRTStartup /base:0x00010000 \ /stack:0x10000,0x1000 /align:4096 /machine:ARM -OUT:hello.exe -pdb:none \ hello.o -nodefaultlib:oldnames.lib -nodefaultlib:libc.lib corelibc.lib \ coredll.lib So it's M$ corelibc.dll and coredll.dll that are being linked against, and the entry point appears to be mainACRTStartup, which resides in corelibc.dll. With GNU ld, I am trying to do this: arm-wince-pe-ld hello.o -o hello.exe -M -e mainACRTStartup \ --image-base 0x00010000 -nostdlib --section-alignment 4096 \ --stack 0x10000 -L../../../lib -L/usr/local/wince/lib/gcc-lib/arm-wince-pe/3.2 \ -lcorelibc -lcoredll -lgcc The link completes successfully, but the results do not run on WinCE 3.0. The test program appears to "hang" before it actually gets into main(). Do you think that we're close to having something that works? > How did you fix the WinCE-headers, so that they would be compatible > with GCC ? My tries with the MIPS and SH toolchains showed the MS- > headers needing very much fixing for GCC... I have done a fair amount of fixing of M$ WinCE 3.0 headers. Usually the things I've had to do are fairly straightforward, like replacing __int64 with "long long". But taken together, a fairly large number of edits have been necessary. This is still a work in progress, but the M$ include files required for my test program are now working correctly with GCC. I'd be happy to provide the modified header files to anyone wanting to work with GCC/arm-wince-pe > As you can see, nobody else can do the same you did and then see > what happens... Telling what you did with the gcc-3.2 sources, what > possible patches and from where, you did install, could be a good > start. Otherwise don't expect others being capable to help you here. Hopefully this submission will go some distance toward rectifying this. I'd like to know: Has anyone else gotten GCC/arm-wince-pe to work with WinCE 3.0? Is arm-wince-pe really a supported configuration for gcc-3.2 as it appears or am I just clueless? > The ARM/EPOC has used probably quite the same 'arm-pe' format as > ARM/WinCE, and if you ask Nokia, Motorola, Samsung, Siemens etc., > they probably claim that GCC works with EPOC when using the > 'arm-epoc-pe' target, at least in the EPOC's own SDKs with GCC... > (available free, Nokia snailmails the SDK6 CDROM if one cannot > download it) > BTW, the Intel/RedHat XScale-toolchain distribution (gcc-3.1) seems > to have the 'arm-wince-pe' support straight from the box. What were > the experiences with this? Both of these are quite interesting to us. Where could we get the Intel/Redhat XScale toolchain distribution? Is that something that Intel provides? I will check it out, and perhaps we can try it. Kai, thank you very much for the assistance. I'm still hoping that we'll find a way to get this working. regards, craig vanderborgh voxware incorporated ------- End of forwarded message ------- ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com ------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |