1) Latest fix for bug 2979 - [GCCE] elf2e32 --dump generates RVCT assembly. Implements Stefan Karlsson's comment #21
2) Merges William Robert's elf2e32 patch re. bug 3359, changset buildtools 77c47a56e1f7
3) Fixes a Windows/Linux path-delimiter bug in romnibus.pl
===============================================================
Things that need done for this package (in no particular order)
===============================================================
2010-05-13, mikek@symbian.org
1. Test the built tools. No testing has been done whatsoever.
2. Build the package on platforms not listed here, and add them to the
list:
Windows XP 32bit
Ubuntu 9.04,10.4 32/64bit
4. Find all the perl scripts that are exported and ensure they run on
Linux.
5. Differentiate the exports so that .bat files are only exported by
Windows builds and .sh files are only exported by *nix builds
6. On Windows, the imgcheck target needs to link against libwsock32.a. This
library exist in the gcc mingw lib directory in the PDT, but because
the library is specified with the STATICLIBRARY keyword, the linker looks
for it in the epoc32\release\tools2\{deb|rel} directory and doesn't find it.
It is not included in the upstream package, so it cannot be exported there.
This bug has been worked around as one of the things done by the
fix_epoc32_win.pl script - it just copies libwsock32.a from the PDT to
the tools2 release deb|rel directories, but a real solution should be found.
Preferably, for all targets on Windows the gcc mingw libraries should be in
the linker's search path.
7. Add a toplevel GNU makefile to the package and scripting to support it which
can generate a GNU tarball containing a "normalised Linux" simplification of
the package. The normalised Linux spin will strip out everything from the
package contents and build that is only required for Windows or would
normally be provided by package prerequisities in a Linux setting, e.g. it
will not contain Windows binaries or build its own versions of make, bash,
cpp, python. A normalised Linux spin would be the right basis on which
to build .deb or .rpm packaging.