harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gregory Shimansky" <gshiman...@gmail.com>
Subject Re: how to build Harmony on Windows (with minimum of commercial soft)
Date Thu, 01 Jun 2006 21:34:58 GMT
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 <davanum@gmail.com>:
>
> 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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message