WinCE SVN Build (27 Feb 07)
Moderator: ScummVM Team
Actually I have completely reinstalled CygWin on my machine, the last version, and I was able to follow the Wiki instructions step by step.
A couple of weeks ago I was forced to play with the version of some tools because I was using a older version of CygWin (1 year old).
Mainly, one needs the following:
-CygWin with dev tools: gcc and make
- sed
- bison
- flex
- texinfo
With the last version for all of them it works
One problem that I have encontered is the encoding of the source files. If the file encoding is DOS than there are problems with cygwin. The solution that worked for me was:
find . -type f -print -exec dos2unix --safe \{\} \;
Regards
Adi
A couple of weeks ago I was forced to play with the version of some tools because I was using a older version of CygWin (1 year old).
Mainly, one needs the following:
-CygWin with dev tools: gcc and make
- sed
- bison
- flex
- texinfo
With the last version for all of them it works
One problem that I have encontered is the encoding of the source files. If the file encoding is DOS than there are problems with cygwin. The solution that worked for me was:
find . -type f -print -exec dos2unix --safe \{\} \;
Regards
Adi
Hi Knakos,
another ideea.
Have you seen the other cross-development tool, cegcc:
http://cegcc.sourceforge.net/
They are providing two different environments mingw32ce and cegcc. From they're documentation:
Regards
Adi
another ideea.
Have you seen the other cross-development tool, cegcc:
http://cegcc.sourceforge.net/
They are providing two different environments mingw32ce and cegcc. From they're documentation:
Both of the tools can be build on Cygwin and I think also in linux
If you want to build an existing Windows CE application that already builds with eVC or MSVC, or you want to develop a Windows CE application that only depends on the Win32 API and the limited libc support coredll.dll (the native runtime) offers, then what you want is mingw32ce.
If you want to port an application that depends on a more complete c runtime, the cegcc toolchain will be a better environment. Cegcc offers unified file descriptors, (in-process only) signals,
Regards
Adi
Thanks for these pointers, I'll add them to the wiki.
During the port transition period, I considered at least 5 gcc toolchains for the job, including the ones you posted. Overall, the current solution had the less severe problems (I later found out about the struct non-packing et cetera), at the time of testing. Further this one is known to work for at least one commercial solution so I'm sticking with it for the time being. If it later becomes obsolete, I may consider changing to another toolchain but for the moment this one works perfectly.
Kostas
During the port transition period, I considered at least 5 gcc toolchains for the job, including the ones you posted. Overall, the current solution had the less severe problems (I later found out about the struct non-packing et cetera), at the time of testing. Further this one is known to work for at least one commercial solution so I'm sticking with it for the time being. If it later becomes obsolete, I may consider changing to another toolchain but for the moment this one works perfectly.
Kostas