Hello I decided to ressurrect this thread because I have some news. At home I decided to try to use as free software as possible and here is what I have.
First I decided to use the current MS free software to repeat what is done by commercial. Nowdays MS offers VS.NET 2005 express edition (no earlier verions are available for download as far as I could find) and Platform SDK Server 2003 R2 (at first I've downloaded an earlier one but later upgraded to 2006 year version). The VS 2005 brings some new nuisances which software written outside of Redmond wasn't ready for. 1. Headers shipped with VS.NET 2005 have new "feature". They warn about unsafe functions which Microsoft replaced with "safe" ones. These includes functions like getenv, sprintf, fopen and probably many others. Compiling sources that use them results in W1 warning and since warnings are treated as errors in native sources compilation fails.The way to fix it is either use new MS functions or define _CRT_SECURE_NO_DEPRECATE (warning message mentions it) and _CRT_NONSTDC_NO_DEPRECATE (warning message doesn't mention it) as described here http://www.wxwidgets.org/wiki/index.php/MSVC_.NET_Setup_Guide I've solved this problem in a different way because I didn't want to change makefiles. It appears that files like stdlib.h in VS.NET distribution have this new "secure" stuff while files in Platform SDK don't. But by default SetEnv.cmd sets $INCLUDE path only to "Platform SDK/Include" directory while files like stdlib.h are located in "Platform SDK/Include/crt" directory. So I added it first into $INCLUDE path in environment and compilation went fine. 2. VS.NET 2005 has some new (at least to me) feature to generate manifests for executables and DLLs. They are external files created alongside of the executables. It appears that they are necessary now for executables to function properly, otherwise they generate an error R6034 ( http://msdn2.microsoft.com/en-us/library/ms235560.aspx). It appears that manifests for applications built with VS.NET 2005 are required to be present either in a form of external .manifest file or embeded into the program or DLL. Right now I didn't find a quick way to embed a manifest into an executable, but just having an external manifest file for every .exe and .dll works. Build system actually copies all *.dll.manifest files into deploy directory but doesn't do it for java.exe.manifest and javaw.exe.manifest files which are created in classlib/trunk/native-src/win.IA32. After resolving those new obstacles I got a fully functional harmony build. Now what next. I had to get MASM in a not quite legal way described by Davanum Srinivas. I unpacked MS Processor Pack executable (it refuses to install unless you have exacly VC 6.0 SP5 installed which is not available for download for a long time) with 7-zip and got MASM executable out of it. I think the best way to change it is to move to NASM which also uses Intel assembly notation but different directives syntax. I have yet to understand the black magic done with CONST segments in locklbl.asm, thrhelp.asm and thrspinlock.asm. The way it is used escapes me. If someone could explain I would be very grateful. I also tried gcc -mno-cygwin with little success. One lesson learned is that sources should be compiled with -DWINVER=0x501 and the compilation succeds. But I have troubles with linking and I just don't have any idea what to do with *.def and *.rc files in cygwin/mingw environment. Any ideas? 2006/3/25, Davanum Srinivas <[EMAIL PROTECTED]>:
Patches are welcome :) Please feel free to send instructions to this list on how to build the pieces using which ever tools you wish to. If there are any patches, please open up new JIRA report and upload the "svn diff" against latest SVN.
-- Gregory Shimansky, Intel Middleware Products Division
