You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Mark Hindess <ma...@googlemail.com> on 2006/06/02 07:18:20 UTC

Re: how to build Harmony on Windows (with minimum of commercial soft)

On 2 June 2006 at 1:34, "Gregory Shimansky" <gs...@gmail.com> wrote:
>
> [ lots of cool stuff about compiling with MS tool chain snipped ]
> 
> 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?

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

HTH,
 Mark.



---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Re: how to build Harmony on Windows (with minimum of commercial soft)

Posted by Gregory Shimansky <gs...@gmail.com>.
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 <ma...@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