wgcc 2.2.0 released

wgcc is a cross-compiler tool primarily written for Microsoft's Interix. Its primary purpose is to produce native Windows binaries (internally using the Microsoft Tool chain), and to mimic the behaviour of the GNU compiler collection. This means that wgcc understands many of GCC's command line arguments, and in most cases delivers the same results as expected, sometimes manipulating the underlying tool's input and output.

Even though wgcc was written for Interix only, it can be used on native Windows (without Interix), and other Systems, like Cygwin. The only restriction is that on Platforms other than Interix, only Windows style paths are understood. With the release of version 2.0.1 this changed. Now Cygwin too is able to convert paths correctly. On Interix (and now Cygwin) wgcc automatically converts UNIX style paths to Windows style ones (i.e. /wgcc to C:\SFU\wgcc).

wgcc abstracts away lots of inconveniences that are introduced by building static libraries, shared libraries (DLL's) and executables with any possible combination of those three. When using wgcc both static and shared libraries behave exactly the same on Windows, and this makes tons of defines unnecessary. The only thing that still has to be done is to give all Data symbols (i.e. Variables) an import attribute (__declspec(dllimport)) when using them (i.e. in the library header files) in an executable. For a simple example take a look at the file tests/shared.test inside the wgcc distribution.

Release 2.2.0 has a major part of wgcc rewritten and a new great improvement added. The rewritten part is the Import Trampoline Generator for static libraries. The backend of this task has been changed to not generate assembler code which is compiled on the fly with ml.exe, but rather generates COFF object code directly. This works around problems with ml.exe (limits of identifier lengths and line lengths in assembler source). Also this solution is a little more performant.

Since this version wgcc accepts configuration options to tweak the sizes and growth steps (commits) of stack and heap of each binary. The Default sizes have been dramatically increased from one megabyte to ten megabyte. This results in a slightly (about ten kilobytes) bigger memory footprint of the initially loaded binary, but brings a lot more stability to UNIX applications relying on a big stack.

Wgcc now understands a commandline option "-subsystem" which allows for linking of Windows Subsystem applications and libraries. This also influences the new loader generator described below. The default subsystem is console and can also be changed in the wgccrc configuration file.

The biggest pack of changes is the new loader generator. This replaces completely the mechanism for dynamic library loading from Windows by a generated loader. This has several advantages:

* The generated loader is subsystem sensitive. If the binary is linked as console application,
error messages are written to stderr, instead of displaying a messagebox like windows does.

* The generated loader is capable of listening to a hardcoded runpath. If a dependant dynamic
library is not found in the runpath directories, the default windows mechanism for loading is used.

* The generated loader publishes a list of dynamic dependencies which can be read by utilities
like the new wldd to resolve and list dependencies.

* The generated loader listens to LD_PRELOAD. This means that it is possible to preload symbols
from libraries not associated with the original application. Unfortunately it is (at the moment)
not possible to preload the runtime libraries, so sandboxing is not possible right now.
This is because msvcrt.lib is quite a complex library mixing shared and static in one file.

The generated loader is, much like the import trampolines now, emitted as object code directly, except of the runpath and dynamic library table, which still requires a little assembler code.

The utilities wldd and wchrpath have been added. Wldd is capable of listing and resolving dynamic dependencies of a binary, just like ldd does on UNIX like systems. As a little "goodie" it is capable of displaying a list of used symbols per binary. Also it is capable of demangling C++ symbol names to produce a human readable list of symbols. Wchrpath can list, delete or change the runpath hardcoded into a binary.

In the PXWC library, the usleep function has been fixed. There was a calculation error making usleep block the process 1000 times too long.

To continue improving wgcc and pxwc packages, we now need your help in testing them. Please download wgcc and try to compile your software using it. If something goes wrong please contact mduft or open an issue using the Sourceforge Tracker at http://sourceforge.net/tracker/?group_id=158081&atid=806404, or ask your questions at the forums at http://sourceforge.net/forum/?group_id=158081.

You can browse the Subversion Repository here: http://svn.sourceforge.net/viewvc/interix-wgcc/trunks/

Documentation can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=203917
Source Packages can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=177049
The Patch for Libtool can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=196163&release_id=446510
The Patch for Autoconf can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=196163&release_id=482833
The PXWC library can be found here: http://sourceforge.net/project/showfiles.php?group_id=158081&package_id=195309