Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of gshimansky@gmail.com designates
 66.249.92.173 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=PYSdBdNa2KMR4iHSD61JQWu1mXBTDKg4lWxboKoLIDxWOOlRD1ajtYGcK2a5sSSz8AuBu1V1bwpk2pNo9F8Jyt6oNasWLPIb02SnG4Q4VuVGVvysMgCqWMCkRITepj02I5SxkTU0TWRwKkkpn49jjX8AOrmeKY6uIPpwGGa7HFE=
Message-ID: <208da7a50606051520h1eafdaeftd8e0de1b71914ec5@mail.gmail.com>
Date: Tue, 6 Jun 2006 02:20:26 +0400
From: "Gregory Shimansky" <gshimansky@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: how to build Harmony on Windows (with minimum of commercial soft)
In-Reply-To: <200606020518.k525ILOE022657@d06av02.portsmouth.uk.ibm.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_15453_6335622.1149546026108"
References: <208da7a50606011434i405b7d5ao4be8a9fefc52e183@mail.gmail.com>
	 <200606020518.k525ILOE022657@d06av02.portsmouth.uk.ibm.com>

------=_Part_15453_6335622.1149546026108
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Thanks a lot for the pointer Mark. I didn't know about windres tool. I think
it may be used to embed manifests which are required for apps built with
VS.NET 2005 as well. I didn't try to do it yet though.

I tried to port MASM code to NASM [1]. I think I've done it although I
didn't test it much. Eclipse works with IBM's VME and as I've added some
debug prints, adresses of lock prefixes to cmpxchg which are replaced by
NOPs in lock386.c in single processor case seem to be correct. I have a
single processor and this code works for me.

One bad thing about NASM is that it cannot write COFF object files with long
segment names. It is limited to 8 symbols and I didn't find a way around it.
So I had to replace long segment names like "CONST$_LOCKFIXUPS_B" with
".rdata$B" in NASM sources. I hope it doesn't cause any segments names
collision.

If anyone is interested I can create a JIRA issue with attached sources.
They may be integrated into build with command line "nasm -f win32 $<" [2]
for nmake.

[1] NASM is free as in speech, it is available under LGPL in Cygwin which
most developers I know use already and it is available independent from
Cygwin from http://sourceforge.net/projects/nasm
[2] If NASM is an executable separate from Cygwin it is called nasmw (for
windows) so the command line may look differently on windows depending on
which way NASM is available.

2006/6/2, Mark Hindess <mark.hindess@googlemail.com>:
>
> I tried using mingw directly a while back - but decided to give up until
> we'd split the natives.  It should be similar to "gcc -mno-cygwin" but
> things just seemed to proceed far more smoothly.
>
> For .rc files, I used a rule like:
>
>   %.res.obj: %.rc
>           windres --include-dir ../include -i $< -o $@
>
> to create .obj files from the .rc files.  (I think that's the right
> thing to do but since I never actually got it working ... )
>
> As for .def files,  I think these can be generated by the linker - and
> we want .lib files created too I think.  You can pass linker options
> from the dll build rule with the -Wl,... option something
> like:
>
> $(DLLNAME): $(BUILDFILES) $(VIRTFILES) $(MDLLIBFILES)
>   $(CC) -shared -o $@ \
>   -Wl,--output-def,${@F:.dll=.def},--out-implib,$(LIBPATH)${@F:.dll=.lib}
> \
>   $(BUILDFILES) $(VIRTFILES) $(MDLLIBFILES) $(SYSLIBFILES) \
>   -lkernel32  -lws2_32 -ladvapi32 -luser32 -lgdi32 -lcomdlg32 -lwinspool
>
-- 
Gregory Shimansky, Intel Middleware Products Division

------=_Part_15453_6335622.1149546026108--