You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@harmony.apache.org by Ivan Zvolsky <i....@gmail.com> on 2007/02/16 16:20:40 UTC
[general] Harmony enabling at Windows / x86_64
Hello,
Some time ago, I found out that Harmony is not buildable on Windows / x86_64
(EM64T).
I tried to reanimate at least the build which has required to update both
classlib and drlvm build files, create stubs for some functions, etc.
I've put my results (for now only classlib part) to HARMONY-3188.
Could someone take a look? The comments are welcome.
In particular, Geir might want to look at the first comment in the
description :)
Thanks,
Ivan
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Gregory,
FYI the issue with manifests was fixed at the revision 511897. Thanks
for pointing this out.
Regards,
2007/2/22, Alexei Zakharov <al...@gmail.com>:
> I'll look at it.
>
> Thanks,
>
> 2007/2/22, Gregory Shimansky <gs...@gmail.com>:
> > Alexei Zakharov wrote:
> > > In my previous letter I was talking about HARMONY-3188 - the classlib
> > > part of the patch. As far as I understand Gregory is currently working
> > > on the DRLVM part. So we will have a full set soon.
> >
> > It looks like classlib build has to embed manifests into DLL and EXE
> > files with command like this for EXE
> >
> > mt.exe -manifest $1.manifest -outputresource:$1;#1
> >
> > and
> >
> > mt.exe -manifest $1.manifest -outputresource:$1;#2
> >
> > is the name of the EXE/DLL file. Without this launcher doesn't start and
> > DLL files cannot be loaded.
> >
> > Also could you please update svn:ignore properties in classlib to ignore
> > all those manifests, vc80.pdb files and new dependency files.
> >
> > > 2007/2/21, Alexei Zakharov <al...@gmail.com>:
> > >> Ok. I've merged all these files together and committed at r510043.
> > >> Please note:
> > >>
> > >> 1. The dependence on ICU 3.6 was dropped. So we still use the version
> > >> 3.4 . IMHO moving to ICU 3.6 should be a separate task, separate JIRA
> > >> should be created and etc.
> > >> 2. I've tested the build on Windows 64 and on 32-bit versions of
> > >> Windows and Linux as well. MSVC 2003 was used on Win32 and MSVC 2005
> > >> on Win64. So I currently don't know is it possible to build the
> > >> classlib using MSVC 2005 on Win32.
> > >> 3. I've added compiled 64-bit version of ICU libs to our depends
> > >> folder: as depends/oss/icu4c-3.4-harmony-windows.x86_64.zip and four
> > >> libs to depends/libs/windows.x86_64
> > >> 4. I put the 64-bit variant of precompiled graphic libs (needed by
> > >> awt-swing) to my home folder at people.apache.org. If someone wants to
> > >> propose another place for these files - he/she is welcome. :)
> > >>
> > >> With Best Regards,
> > >>
> > >> 2007/2/21, Ivan Zvolsky <i....@gmail.com>:
> > >> > On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
> > >> > >
> > >> > > Thanks Ivan, the build was successful this time. However, I've spent
> > >> > > some time trying to resolve strange x32-x64 conflict (even with your
> > >> > > new patch) and found that "clean" target doesn't work as expected.
> > >> And
> > >> > > it seems that the root cause of it is your modification:
> > >> > >
> > >> > > in modules\portlib\src\main\native\thread\makefile:
> > >> > > ---
> > >> > > BUILDFILES = \
> > >> > > $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
> > >> > > $(HY_PLATFORM)/thrspinlock.obj \
> > >> > > $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
> > >> > > $(SHAREDSUB)rwmutex.obj thrdsup.obj \
> > >> > > $(SHAREDSUB)thrprof.obj
> > >> > >
> > >> > > in modules\portlib\src\main\native\common\windows\makefile:
> > >> > > --
> > >> > > BUILDFILES = \
> > >> > > $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
> > >> > > $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
> > >> > > $(HY_PLATFORM)/locklbl.obj lock386.obj \
> > >> > > $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
> > >> > >
> > >> > > I mean "$(HY_PLATFORM)/thrspinlock.obj" and
> > >> > > "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
> > >> > > "/". Could you fix this somehow please?
> > >> >
> > >> >
> > >> > Well, since these makefiles are intended to work on windows,
> > >> replacing slash
> > >> > with backslash should work. I just tried this and it worked fine. So
> > >> I've
> > >> > updated the patch in H-3188.
> > >> >
> > >
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
I'll look at it.
Thanks,
2007/2/22, Gregory Shimansky <gs...@gmail.com>:
> Alexei Zakharov wrote:
> > In my previous letter I was talking about HARMONY-3188 - the classlib
> > part of the patch. As far as I understand Gregory is currently working
> > on the DRLVM part. So we will have a full set soon.
>
> It looks like classlib build has to embed manifests into DLL and EXE
> files with command like this for EXE
>
> mt.exe -manifest $1.manifest -outputresource:$1;#1
>
> and
>
> mt.exe -manifest $1.manifest -outputresource:$1;#2
>
> is the name of the EXE/DLL file. Without this launcher doesn't start and
> DLL files cannot be loaded.
>
> Also could you please update svn:ignore properties in classlib to ignore
> all those manifests, vc80.pdb files and new dependency files.
>
> > 2007/2/21, Alexei Zakharov <al...@gmail.com>:
> >> Ok. I've merged all these files together and committed at r510043.
> >> Please note:
> >>
> >> 1. The dependence on ICU 3.6 was dropped. So we still use the version
> >> 3.4 . IMHO moving to ICU 3.6 should be a separate task, separate JIRA
> >> should be created and etc.
> >> 2. I've tested the build on Windows 64 and on 32-bit versions of
> >> Windows and Linux as well. MSVC 2003 was used on Win32 and MSVC 2005
> >> on Win64. So I currently don't know is it possible to build the
> >> classlib using MSVC 2005 on Win32.
> >> 3. I've added compiled 64-bit version of ICU libs to our depends
> >> folder: as depends/oss/icu4c-3.4-harmony-windows.x86_64.zip and four
> >> libs to depends/libs/windows.x86_64
> >> 4. I put the 64-bit variant of precompiled graphic libs (needed by
> >> awt-swing) to my home folder at people.apache.org. If someone wants to
> >> propose another place for these files - he/she is welcome. :)
> >>
> >> With Best Regards,
> >>
> >> 2007/2/21, Ivan Zvolsky <i....@gmail.com>:
> >> > On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
> >> > >
> >> > > Thanks Ivan, the build was successful this time. However, I've spent
> >> > > some time trying to resolve strange x32-x64 conflict (even with your
> >> > > new patch) and found that "clean" target doesn't work as expected.
> >> And
> >> > > it seems that the root cause of it is your modification:
> >> > >
> >> > > in modules\portlib\src\main\native\thread\makefile:
> >> > > ---
> >> > > BUILDFILES = \
> >> > > $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
> >> > > $(HY_PLATFORM)/thrspinlock.obj \
> >> > > $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
> >> > > $(SHAREDSUB)rwmutex.obj thrdsup.obj \
> >> > > $(SHAREDSUB)thrprof.obj
> >> > >
> >> > > in modules\portlib\src\main\native\common\windows\makefile:
> >> > > --
> >> > > BUILDFILES = \
> >> > > $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
> >> > > $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
> >> > > $(HY_PLATFORM)/locklbl.obj lock386.obj \
> >> > > $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
> >> > >
> >> > > I mean "$(HY_PLATFORM)/thrspinlock.obj" and
> >> > > "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
> >> > > "/". Could you fix this somehow please?
> >> >
> >> >
> >> > Well, since these makefiles are intended to work on windows,
> >> replacing slash
> >> > with backslash should work. I just tried this and it worked fine. So
> >> I've
> >> > updated the patch in H-3188.
> >> >
> >
> >
>
>
> --
> Gregory
>
>
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexei Zakharov wrote:
> In my previous letter I was talking about HARMONY-3188 - the classlib
> part of the patch. As far as I understand Gregory is currently working
> on the DRLVM part. So we will have a full set soon.
It looks like classlib build has to embed manifests into DLL and EXE
files with command like this for EXE
mt.exe -manifest $1.manifest -outputresource:$1;#1
and
mt.exe -manifest $1.manifest -outputresource:$1;#2
is the name of the EXE/DLL file. Without this launcher doesn't start and
DLL files cannot be loaded.
Also could you please update svn:ignore properties in classlib to ignore
all those manifests, vc80.pdb files and new dependency files.
> 2007/2/21, Alexei Zakharov <al...@gmail.com>:
>> Ok. I've merged all these files together and committed at r510043.
>> Please note:
>>
>> 1. The dependence on ICU 3.6 was dropped. So we still use the version
>> 3.4 . IMHO moving to ICU 3.6 should be a separate task, separate JIRA
>> should be created and etc.
>> 2. I've tested the build on Windows 64 and on 32-bit versions of
>> Windows and Linux as well. MSVC 2003 was used on Win32 and MSVC 2005
>> on Win64. So I currently don't know is it possible to build the
>> classlib using MSVC 2005 on Win32.
>> 3. I've added compiled 64-bit version of ICU libs to our depends
>> folder: as depends/oss/icu4c-3.4-harmony-windows.x86_64.zip and four
>> libs to depends/libs/windows.x86_64
>> 4. I put the 64-bit variant of precompiled graphic libs (needed by
>> awt-swing) to my home folder at people.apache.org. If someone wants to
>> propose another place for these files - he/she is welcome. :)
>>
>> With Best Regards,
>>
>> 2007/2/21, Ivan Zvolsky <i....@gmail.com>:
>> > On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
>> > >
>> > > Thanks Ivan, the build was successful this time. However, I've spent
>> > > some time trying to resolve strange x32-x64 conflict (even with your
>> > > new patch) and found that "clean" target doesn't work as expected.
>> And
>> > > it seems that the root cause of it is your modification:
>> > >
>> > > in modules\portlib\src\main\native\thread\makefile:
>> > > ---
>> > > BUILDFILES = \
>> > > $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
>> > > $(HY_PLATFORM)/thrspinlock.obj \
>> > > $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
>> > > $(SHAREDSUB)rwmutex.obj thrdsup.obj \
>> > > $(SHAREDSUB)thrprof.obj
>> > >
>> > > in modules\portlib\src\main\native\common\windows\makefile:
>> > > --
>> > > BUILDFILES = \
>> > > $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
>> > > $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
>> > > $(HY_PLATFORM)/locklbl.obj lock386.obj \
>> > > $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
>> > >
>> > > I mean "$(HY_PLATFORM)/thrspinlock.obj" and
>> > > "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
>> > > "/". Could you fix this somehow please?
>> >
>> >
>> > Well, since these makefiles are intended to work on windows,
>> replacing slash
>> > with backslash should work. I just tried this and it worked fine. So
>> I've
>> > updated the patch in H-3188.
>> >
>
>
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
In my previous letter I was talking about HARMONY-3188 - the classlib
part of the patch. As far as I understand Gregory is currently working
on the DRLVM part. So we will have a full set soon.
Thanks,
2007/2/21, Alexei Zakharov <al...@gmail.com>:
> Ok. I've merged all these files together and committed at r510043. Please note:
>
> 1. The dependence on ICU 3.6 was dropped. So we still use the version
> 3.4 . IMHO moving to ICU 3.6 should be a separate task, separate JIRA
> should be created and etc.
> 2. I've tested the build on Windows 64 and on 32-bit versions of
> Windows and Linux as well. MSVC 2003 was used on Win32 and MSVC 2005
> on Win64. So I currently don't know is it possible to build the
> classlib using MSVC 2005 on Win32.
> 3. I've added compiled 64-bit version of ICU libs to our depends
> folder: as depends/oss/icu4c-3.4-harmony-windows.x86_64.zip and four
> libs to depends/libs/windows.x86_64
> 4. I put the 64-bit variant of precompiled graphic libs (needed by
> awt-swing) to my home folder at people.apache.org. If someone wants to
> propose another place for these files - he/she is welcome. :)
>
> With Best Regards,
>
> 2007/2/21, Ivan Zvolsky <i....@gmail.com>:
> > On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
> > >
> > > Thanks Ivan, the build was successful this time. However, I've spent
> > > some time trying to resolve strange x32-x64 conflict (even with your
> > > new patch) and found that "clean" target doesn't work as expected. And
> > > it seems that the root cause of it is your modification:
> > >
> > > in modules\portlib\src\main\native\thread\makefile:
> > > ---
> > > BUILDFILES = \
> > > $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
> > > $(HY_PLATFORM)/thrspinlock.obj \
> > > $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
> > > $(SHAREDSUB)rwmutex.obj thrdsup.obj \
> > > $(SHAREDSUB)thrprof.obj
> > >
> > > in modules\portlib\src\main\native\common\windows\makefile:
> > > --
> > > BUILDFILES = \
> > > $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
> > > $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
> > > $(HY_PLATFORM)/locklbl.obj lock386.obj \
> > > $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
> > >
> > > I mean "$(HY_PLATFORM)/thrspinlock.obj" and
> > > "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
> > > "/". Could you fix this somehow please?
> >
> >
> > Well, since these makefiles are intended to work on windows, replacing slash
> > with backslash should work. I just tried this and it worked fine. So I've
> > updated the patch in H-3188.
> >
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
Ok. I've merged all these files together and committed at r510043. Please note:
1. The dependence on ICU 3.6 was dropped. So we still use the version
3.4 . IMHO moving to ICU 3.6 should be a separate task, separate JIRA
should be created and etc.
2. I've tested the build on Windows 64 and on 32-bit versions of
Windows and Linux as well. MSVC 2003 was used on Win32 and MSVC 2005
on Win64. So I currently don't know is it possible to build the
classlib using MSVC 2005 on Win32.
3. I've added compiled 64-bit version of ICU libs to our depends
folder: as depends/oss/icu4c-3.4-harmony-windows.x86_64.zip and four
libs to depends/libs/windows.x86_64
4. I put the 64-bit variant of precompiled graphic libs (needed by
awt-swing) to my home folder at people.apache.org. If someone wants to
propose another place for these files - he/she is welcome. :)
With Best Regards,
2007/2/21, Ivan Zvolsky <i....@gmail.com>:
> On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
> >
> > Thanks Ivan, the build was successful this time. However, I've spent
> > some time trying to resolve strange x32-x64 conflict (even with your
> > new patch) and found that "clean" target doesn't work as expected. And
> > it seems that the root cause of it is your modification:
> >
> > in modules\portlib\src\main\native\thread\makefile:
> > ---
> > BUILDFILES = \
> > $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
> > $(HY_PLATFORM)/thrspinlock.obj \
> > $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
> > $(SHAREDSUB)rwmutex.obj thrdsup.obj \
> > $(SHAREDSUB)thrprof.obj
> >
> > in modules\portlib\src\main\native\common\windows\makefile:
> > --
> > BUILDFILES = \
> > $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
> > $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
> > $(HY_PLATFORM)/locklbl.obj lock386.obj \
> > $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
> >
> > I mean "$(HY_PLATFORM)/thrspinlock.obj" and
> > "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
> > "/". Could you fix this somehow please?
>
>
> Well, since these makefiles are intended to work on windows, replacing slash
> with backslash should work. I just tried this and it worked fine. So I've
> updated the patch in H-3188.
>
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Ivan Zvolsky <i....@gmail.com>.
On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
>
> Thanks Ivan, the build was successful this time. However, I've spent
> some time trying to resolve strange x32-x64 conflict (even with your
> new patch) and found that "clean" target doesn't work as expected. And
> it seems that the root cause of it is your modification:
>
> in modules\portlib\src\main\native\thread\makefile:
> ---
> BUILDFILES = \
> $(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
> $(HY_PLATFORM)/thrspinlock.obj \
> $(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
> $(SHAREDSUB)rwmutex.obj thrdsup.obj \
> $(SHAREDSUB)thrprof.obj
>
> in modules\portlib\src\main\native\common\windows\makefile:
> --
> BUILDFILES = \
> $(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
> $(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
> $(HY_PLATFORM)/locklbl.obj lock386.obj \
> $(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
>
> I mean "$(HY_PLATFORM)/thrspinlock.obj" and
> "$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
> "/". Could you fix this somehow please?
Well, since these makefiles are intended to work on windows, replacing slash
with backslash should work. I just tried this and it worked fine. So I've
updated the patch in H-3188.
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
Thanks Ivan, the build was successful this time. However, I've spent
some time trying to resolve strange x32-x64 conflict (even with your
new patch) and found that "clean" target doesn't work as expected. And
it seems that the root cause of it is your modification:
in modules\portlib\src\main\native\thread\makefile:
---
BUILDFILES = \
$(SHAREDSUB)thread_copyright.obj $(HY_PLATFORM)/thrhelp.obj
$(HY_PLATFORM)/thrspinlock.obj \
$(SHAREDSUB)hythread.obj $(SHAREDSUB)hythreadinspect.obj
$(SHAREDSUB)rwmutex.obj thrdsup.obj \
$(SHAREDSUB)thrprof.obj
in modules\portlib\src\main\native\common\windows\makefile:
--
BUILDFILES = \
$(SHAREDSUB)libglob.obj $(SHAREDSUB)iohelp.obj \
$(SHAREDSUB)exceptions.obj $(SHAREDSUB)strhelp.obj \
$(HY_PLATFORM)/locklbl.obj lock386.obj \
$(SHAREDSUB)utf8decode.obj $(SHAREDSUB)utf8encode.obj
I mean "$(HY_PLATFORM)/thrspinlock.obj" and
"$(HY_PLATFORM)/locklbl.obj". Seems Windows del command cannot handle
"/". Could you fix this somehow please?
Thanks,
2007/2/20, Ivan Zvolsky <i....@gmail.com>:
> Hello,
>
> This is because wrong version (not x64) of macro assembler were used to
> compile locklbl.obj due to my mistake in build system patch. ml64.exe should
> be used instead of ml.exe. I've fixed this in the latest version of the
> patch and updated H-3188 with it (see classlib_build_system_v2.patch).
>
> On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
> >
> > Ivan,
> >
> > I have problems with compiling the native part of classlib+your patch
> > on Win64. I've got the following:
> >
> > -build-native:
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\libglob.obj ..\shared\libglob.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] libglob.c
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\iohelp.obj ..\shared\iohelp.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] iohelp.c
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\exceptions.obj ..\shared\exceptions.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] exceptions.c
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\strhelp.obj ..\shared\strhelp.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] strhelp.c
> > [exec] ml /Fowindows.x86_64/locklbl.obj /c /Cp /W3 /nologo
> > /coff /Zm /Zd /Zi /Gd -DWI
> > N32 windows.x86_64/locklbl.asm
> > [exec] Assembling: windows.x86_64/locklbl.asm
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Folock386.obj lock386.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] lock386.c
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\utf8decode.obj ..\shared\utf8decode.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] utf8decode.c
> > [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> > -FIsehmap.h -D_AMD64_=1 -DW
> > IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> > -D_WIN32_WINDOWS=0x0400 /D_WIN
> > 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> > -Zm400 -D_DLL -D_MT -D_WINS
> > OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> > /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> > -Fo..\shared\utf8encode.obj ..\shared\utf8encode.c
> > [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> > [exec] utf8encode.c
> > [exec] lib /NOLOGO -subsystem:windows
> > -out:C:\ayza_docs\cl\deploy\lib\hycommon.lib -
> > machine:AMD64 ..\shared\libglob.obj ..\shared\iohelp.obj
> > ..\shared\exceptions.obj ..\shared\s
> > trhelp.obj windows.x86_64/locklbl.obj lock386.obj
> > ..\shared\utf8decode.obj ..\shared\utf8enco
> > de.obj
> > [exec] windows.x86_64/locklbl.obj : fatal error LNK1112: module
> > machine type 'X86' conflic
> > ts with target machine type 'x64'
> > [exec] NMAKE : fatal error U1077: '"C:\Program Files
> > (x86)\Microsoft Visual Studio 8\VC\BI
> > N\amd64\lib.EXE"' : return code '0x458'
> > [exec] Stop.
> >
> > Any ideas?
> >
> > Thanks,
> >
> > 2007/2/16, Ivan Zvolsky <i....@gmail.com>:
> > > Hello,
> > >
> > > Some time ago, I found out that Harmony is not buildable on Windows /
> > x86_64
> > > (EM64T).
> > > I tried to reanimate at least the build which has required to update
> > both
> > > classlib and drlvm build files, create stubs for some functions, etc.
> > >
> > > I've put my results (for now only classlib part) to HARMONY-3188.
> > > Could someone take a look? The comments are welcome.
> > >
> > > In particular, Geir might want to look at the first comment in the
> > > description :)
> > >
> > > Thanks,
> > > Ivan
> > --
> > Alexei Zakharov,
> > Intel ESSD
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Ivan Zvolsky <i....@gmail.com>.
Hello,
This is because wrong version (not x64) of macro assembler were used to
compile locklbl.obj due to my mistake in build system patch. ml64.exe should
be used instead of ml.exe. I've fixed this in the latest version of the
patch and updated H-3188 with it (see classlib_build_system_v2.patch).
On 2/20/07, Alexei Zakharov <al...@gmail.com> wrote:
>
> Ivan,
>
> I have problems with compiling the native part of classlib+your patch
> on Win64. I've got the following:
>
> -build-native:
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\libglob.obj ..\shared\libglob.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] libglob.c
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\iohelp.obj ..\shared\iohelp.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] iohelp.c
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\exceptions.obj ..\shared\exceptions.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] exceptions.c
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\strhelp.obj ..\shared\strhelp.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] strhelp.c
> [exec] ml /Fowindows.x86_64/locklbl.obj /c /Cp /W3 /nologo
> /coff /Zm /Zd /Zi /Gd -DWI
> N32 windows.x86_64/locklbl.asm
> [exec] Assembling: windows.x86_64/locklbl.asm
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Folock386.obj lock386.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] lock386.c
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\utf8decode.obj ..\shared\utf8decode.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] utf8decode.c
> [exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
> -FIsehmap.h -D_AMD64_=1 -DW
> IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
> -D_WIN32_WINDOWS=0x0400 /D_WIN
> 32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
> -Zm400 -D_DLL -D_MT -D_WINS
> OCKAPI_ /IC:\ayza_docs\cl\deploy\include
> /IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
> -Fo..\shared\utf8encode.obj ..\shared\utf8encode.c
> [exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
> [exec] utf8encode.c
> [exec] lib /NOLOGO -subsystem:windows
> -out:C:\ayza_docs\cl\deploy\lib\hycommon.lib -
> machine:AMD64 ..\shared\libglob.obj ..\shared\iohelp.obj
> ..\shared\exceptions.obj ..\shared\s
> trhelp.obj windows.x86_64/locklbl.obj lock386.obj
> ..\shared\utf8decode.obj ..\shared\utf8enco
> de.obj
> [exec] windows.x86_64/locklbl.obj : fatal error LNK1112: module
> machine type 'X86' conflic
> ts with target machine type 'x64'
> [exec] NMAKE : fatal error U1077: '"C:\Program Files
> (x86)\Microsoft Visual Studio 8\VC\BI
> N\amd64\lib.EXE"' : return code '0x458'
> [exec] Stop.
>
> Any ideas?
>
> Thanks,
>
> 2007/2/16, Ivan Zvolsky <i....@gmail.com>:
> > Hello,
> >
> > Some time ago, I found out that Harmony is not buildable on Windows /
> x86_64
> > (EM64T).
> > I tried to reanimate at least the build which has required to update
> both
> > classlib and drlvm build files, create stubs for some functions, etc.
> >
> > I've put my results (for now only classlib part) to HARMONY-3188.
> > Could someone take a look? The comments are welcome.
> >
> > In particular, Geir might want to look at the first comment in the
> > description :)
> >
> > Thanks,
> > Ivan
>
> --
> Alexei Zakharov,
> Intel ESSD
>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
Ivan,
I have problems with compiling the native part of classlib+your patch
on Win64. I've got the following:
-build-native:
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\libglob.obj ..\shared\libglob.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] libglob.c
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\iohelp.obj ..\shared\iohelp.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] iohelp.c
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\exceptions.obj ..\shared\exceptions.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] exceptions.c
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\strhelp.obj ..\shared\strhelp.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] strhelp.c
[exec] ml /Fowindows.x86_64/locklbl.obj /c /Cp /W3 /nologo
/coff /Zm /Zd /Zi /Gd -DWI
N32 windows.x86_64/locklbl.asm
[exec] Assembling: windows.x86_64/locklbl.asm
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Folock386.obj lock386.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] lock386.c
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\utf8decode.obj ..\shared\utf8decode.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] utf8decode.c
[exec] cl -c -DCRTAPI1=_cdecl -DCRTAPI2=_cdecl -nologo -GS
-FIsehmap.h -D_AMD64_=1 -DW
IN64 -D_WIN64 -DWIN32 -D_WIN32 /FIPRE64PRA.H -Wp64 -W4 -D_WIN95
-D_WIN32_WINDOWS=0x0400 /D_WIN
32_DCOM -D_WIN32_IE=0x0500 -DWINVER=0x0400 -Zi -Od -W0 -GF -Gs -MD
-Zm400 -D_DLL -D_MT -D_WINS
OCKAPI_ /IC:\ayza_docs\cl\deploy\include
/IC:\ayza_docs\cl\deploy\jdk\include /I. /I..\shared\
-Fo..\shared\utf8encode.obj ..\shared\utf8encode.c
[exec] cl : Command line warning D9025 : overriding '/W4' with '/W0'
[exec] utf8encode.c
[exec] lib /NOLOGO -subsystem:windows
-out:C:\ayza_docs\cl\deploy\lib\hycommon.lib -
machine:AMD64 ..\shared\libglob.obj ..\shared\iohelp.obj
..\shared\exceptions.obj ..\shared\s
trhelp.obj windows.x86_64/locklbl.obj lock386.obj
..\shared\utf8decode.obj ..\shared\utf8enco
de.obj
[exec] windows.x86_64/locklbl.obj : fatal error LNK1112: module
machine type 'X86' conflic
ts with target machine type 'x64'
[exec] NMAKE : fatal error U1077: '"C:\Program Files
(x86)\Microsoft Visual Studio 8\VC\BI
N\amd64\lib.EXE"' : return code '0x458'
[exec] Stop.
Any ideas?
Thanks,
2007/2/16, Ivan Zvolsky <i....@gmail.com>:
> Hello,
>
> Some time ago, I found out that Harmony is not buildable on Windows / x86_64
> (EM64T).
> I tried to reanimate at least the build which has required to update both
> classlib and drlvm build files, create stubs for some functions, etc.
>
> I've put my results (for now only classlib part) to HARMONY-3188.
> Could someone take a look? The comments are welcome.
>
> In particular, Geir might want to look at the first comment in the
> description :)
>
> Thanks,
> Ivan
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Feb 16, 2007, at 10:20 AM, Ivan Zvolsky wrote:
>
>> Hello,
>>
>> Some time ago, I found out that Harmony is not buildable on Windows /
>> x86_64
>> (EM64T).
>> I tried to reanimate at least the build which has required to update both
>> classlib and drlvm build files, create stubs for some functions, etc.
>>
>> I've put my results (for now only classlib part) to HARMONY-3188.
>> Could someone take a look? The comments are welcome.
>>
>> In particular, Geir might want to look at the first comment in the
>> description :)
>
> Heh. I can host these too, or we can find another place.
Right now they are accessible directly from JIRA like [1] from
HARMONY-3196. Is it ok to use such links?
[1]
http://issues.apache.org/jira/secure/attachment/12351498/zlib-x86_64-dll.zip
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 16, 2007, at 10:20 AM, Ivan Zvolsky wrote:
> Hello,
>
> Some time ago, I found out that Harmony is not buildable on
> Windows / x86_64
> (EM64T).
> I tried to reanimate at least the build which has required to
> update both
> classlib and drlvm build files, create stubs for some functions, etc.
>
> I've put my results (for now only classlib part) to HARMONY-3188.
> Could someone take a look? The comments are welcome.
>
> In particular, Geir might want to look at the first comment in the
> description :)
Heh. I can host these too, or we can find another place.
thanks for the patch
>
> Thanks,
> Ivan
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Feb 20, 2007, at 7:23 AM, Gregory Shimansky wrote:
>
>> Geir Magnusson Jr. wrote:
>>> On Feb 19, 2007, at 3:49 PM, Gregory Shimansky wrote:
>>>> Alexei Zakharov wrote:
>>>>> Hi Ivan,
>>>>> Thank you for doing this first of all. IMO patches look good in
>>>>> general. However, I'd like to emphasize two things (I've already told
>>>>> you in private about them) and let others to comment on it.
>>>>> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
>>>>> instead of msvcr71.dll for example. Currently MSVC 2003 is required
>>>>> for building the classlib. However, MSVC 2005 adds extensive support
>>>>> for developing of 64bit applications and it looks like a natural
>>>>> choice for 64bit Windows platform. So am +1 for supporting both MSVCs.
>>>>> But I also would like to know if there are any other opinions.
>>>>
>>>> I think it would be good if we had a choice of microsoft tools
>>>> version. If we can support MSVC 2005 on x86_64, why not allow to use
>>>> it on x86 too? The only freely available development environment
>>>> from MS site is MSVC 2005 Community Edition. So if we support it, it
>>>> will help development for x86 version of windows.
>>>>
>>> Well... does it work? besides the rt dll issue, what else is
>>> there? Is nmake backwards compatible? I thought one problem was
>>> that 2005 was missing something that 2003 had...
>>
>> I am not aware of anything missing in 2005. There are two problems
>> with it. It introduced new "secure" versions of functions like strcmp
>> and deprecated the standard C API. Including standard headers produces
>> many warnings that the functions are now deprecated. But it can be
>> worked around by adding two defines to the compiler command line to
>> make headers backwards compatible.
>
> Right - I remember that - I was trying to use 2005 a while ago, and came
> to the same conclusion.
>
>>
>> Another problem is some new manifests stuff which I don't know very
>> well. Apparently now when linker produces a dll or exe file it also
>> creates a manifest which should be either present in the same
>> directory, or be embedded inside of the executable or dll.
>
> That seems simple enough.
>
>>
>> Both of the above problems are probably solved in the patches by Ivan,
>> so these solutions may be applied to the x86 version as well to allow
>> people to use MSVC 2005 on plain 32-bit windows.
>>
>
> Lets just be sure we don't hurt the 2003 users :)
Absolutely. I just said that we could have 2005 as an option on x86
windows, not that we should switch to it.
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 20, 2007, at 7:23 AM, Gregory Shimansky wrote:
> Geir Magnusson Jr. wrote:
>> On Feb 19, 2007, at 3:49 PM, Gregory Shimansky wrote:
>>> Alexei Zakharov wrote:
>>>> Hi Ivan,
>>>> Thank you for doing this first of all. IMO patches look good in
>>>> general. However, I'd like to emphasize two things (I've already
>>>> told
>>>> you in private about them) and let others to comment on it.
>>>> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
>>>> instead of msvcr71.dll for example. Currently MSVC 2003 is required
>>>> for building the classlib. However, MSVC 2005 adds extensive
>>>> support
>>>> for developing of 64bit applications and it looks like a natural
>>>> choice for 64bit Windows platform. So am +1 for supporting both
>>>> MSVCs.
>>>> But I also would like to know if there are any other opinions.
>>>
>>> I think it would be good if we had a choice of microsoft tools
>>> version. If we can support MSVC 2005 on x86_64, why not allow to
>>> use it on x86 too? The only freely available development
>>> environment from MS site is MSVC 2005 Community Edition. So if we
>>> support it, it will help development for x86 version of windows.
>>>
>> Well... does it work? besides the rt dll issue, what else is
>> there? Is nmake backwards compatible? I thought one problem was
>> that 2005 was missing something that 2003 had...
>
> I am not aware of anything missing in 2005. There are two problems
> with it. It introduced new "secure" versions of functions like
> strcmp and deprecated the standard C API. Including standard
> headers produces many warnings that the functions are now
> deprecated. But it can be worked around by adding two defines to
> the compiler command line to make headers backwards compatible.
Right - I remember that - I was trying to use 2005 a while ago, and
came to the same conclusion.
>
> Another problem is some new manifests stuff which I don't know very
> well. Apparently now when linker produces a dll or exe file it also
> creates a manifest which should be either present in the same
> directory, or be embedded inside of the executable or dll.
That seems simple enough.
>
> Both of the above problems are probably solved in the patches by
> Ivan, so these solutions may be applied to the x86 version as well
> to allow people to use MSVC 2005 on plain 32-bit windows.
>
Lets just be sure we don't hurt the 2003 users :)
geir
> --
> Gregory
>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Feb 19, 2007, at 3:49 PM, Gregory Shimansky wrote:
>
>> Alexei Zakharov wrote:
>>> Hi Ivan,
>>> Thank you for doing this first of all. IMO patches look good in
>>> general. However, I'd like to emphasize two things (I've already told
>>> you in private about them) and let others to comment on it.
>>> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
>>> instead of msvcr71.dll for example. Currently MSVC 2003 is required
>>> for building the classlib. However, MSVC 2005 adds extensive support
>>> for developing of 64bit applications and it looks like a natural
>>> choice for 64bit Windows platform. So am +1 for supporting both MSVCs.
>>> But I also would like to know if there are any other opinions.
>>
>> I think it would be good if we had a choice of microsoft tools
>> version. If we can support MSVC 2005 on x86_64, why not allow to use
>> it on x86 too? The only freely available development environment from
>> MS site is MSVC 2005 Community Edition. So if we support it, it will
>> help development for x86 version of windows.
>>
>
> Well... does it work? besides the rt dll issue, what else is there?
> Is nmake backwards compatible? I thought one problem was that 2005 was
> missing something that 2003 had...
I am not aware of anything missing in 2005. There are two problems with
it. It introduced new "secure" versions of functions like strcmp and
deprecated the standard C API. Including standard headers produces many
warnings that the functions are now deprecated. But it can be worked
around by adding two defines to the compiler command line to make
headers backwards compatible.
Another problem is some new manifests stuff which I don't know very
well. Apparently now when linker produces a dll or exe file it also
creates a manifest which should be either present in the same directory,
or be embedded inside of the executable or dll.
Both of the above problems are probably solved in the patches by Ivan,
so these solutions may be applied to the x86 version as well to allow
people to use MSVC 2005 on plain 32-bit windows.
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 19, 2007, at 3:49 PM, Gregory Shimansky wrote:
> Alexei Zakharov wrote:
>> Hi Ivan,
>> Thank you for doing this first of all. IMO patches look good in
>> general. However, I'd like to emphasize two things (I've already told
>> you in private about them) and let others to comment on it.
>> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
>> instead of msvcr71.dll for example. Currently MSVC 2003 is required
>> for building the classlib. However, MSVC 2005 adds extensive support
>> for developing of 64bit applications and it looks like a natural
>> choice for 64bit Windows platform. So am +1 for supporting both
>> MSVCs.
>> But I also would like to know if there are any other opinions.
>
> I think it would be good if we had a choice of microsoft tools
> version. If we can support MSVC 2005 on x86_64, why not allow to
> use it on x86 too? The only freely available development
> environment from MS site is MSVC 2005 Community Edition. So if we
> support it, it will help development for x86 version of windows.
>
Well... does it work? besides the rt dll issue, what else is
there? Is nmake backwards compatible? I thought one problem was
that 2005 was missing something that 2003 had...
geir
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Alexei Zakharov wrote:
> Hi Ivan,
>
> Thank you for doing this first of all. IMO patches look good in
> general. However, I'd like to emphasize two things (I've already told
> you in private about them) and let others to comment on it.
>
> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
> instead of msvcr71.dll for example. Currently MSVC 2003 is required
> for building the classlib. However, MSVC 2005 adds extensive support
> for developing of 64bit applications and it looks like a natural
> choice for 64bit Windows platform. So am +1 for supporting both MSVCs.
> But I also would like to know if there are any other opinions.
I think it would be good if we had a choice of microsoft tools version.
If we can support MSVC 2005 on x86_64, why not allow to use it on x86
too? The only freely available development environment from MS site is
MSVC 2005 Community Edition. So if we support it, it will help
development for x86 version of windows.
> 2. You suggest using new ICU version 3.6. However, the version *3.4*
> is currently used in the classlib. I don't like to say that version
> 3.4 is better than version 3.6. However, there is the neighbour thread
> called "[general] Update to a new version of ICU" here in list. So IMO
> we should finalize that discussion before moving to the version 3.6
>
> Thanks,
>
> 2007/2/16, Ivan Zvolsky <i....@gmail.com>:
>> Hello,
>>
>> Some time ago, I found out that Harmony is not buildable on Windows /
>> x86_64
>> (EM64T).
>> I tried to reanimate at least the build which has required to update both
>> classlib and drlvm build files, create stubs for some functions, etc.
>>
>> I've put my results (for now only classlib part) to HARMONY-3188.
>> Could someone take a look? The comments are welcome.
>>
>> In particular, Geir might want to look at the first comment in the
>> description :)
>>
>> Thanks,
>> Ivan
>>
>
>
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 19, 2007, at 2:46 PM, Alexei Zakharov wrote:
> Hi Ivan,
>
> Thank you for doing this first of all. IMO patches look good in
> general. However, I'd like to emphasize two things (I've already told
> you in private about them) and let others to comment on it.
>
> 1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
> instead of msvcr71.dll for example. Currently MSVC 2003 is required
> for building the classlib. However, MSVC 2005 adds extensive support
> for developing of 64bit applications and it looks like a natural
> choice for 64bit Windows platform. So am +1 for supporting both MSVCs.
> But I also would like to know if there are any other opinions.
This is only for 64bit right?
>
> 2. You suggest using new ICU version 3.6. However, the version *3.4*
> is currently used in the classlib. I don't like to say that version
> 3.4 is better than version 3.6. However, there is the neighbour thread
> called "[general] Update to a new version of ICU" here in list. So IMO
> we should finalize that discussion before moving to the version 3.6
y
>
> Thanks,
>
> 2007/2/16, Ivan Zvolsky <i....@gmail.com>:
>> Hello,
>>
>> Some time ago, I found out that Harmony is not buildable on
>> Windows / x86_64
>> (EM64T).
>> I tried to reanimate at least the build which has required to
>> update both
>> classlib and drlvm build files, create stubs for some functions, etc.
>>
>> I've put my results (for now only classlib part) to HARMONY-3188.
>> Could someone take a look? The comments are welcome.
>>
>> In particular, Geir might want to look at the first comment in the
>> description :)
>>
>> Thanks,
>> Ivan
>>
>
>
> --
> Alexei Zakharov,
> Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by Alexei Zakharov <al...@gmail.com>.
Hi Ivan,
Thank you for doing this first of all. IMO patches look good in
general. However, I'd like to emphasize two things (I've already told
you in private about them) and let others to comment on it.
1. In your patch you suggest to use MSVC 2005 - msvcr80.dll is used
instead of msvcr71.dll for example. Currently MSVC 2003 is required
for building the classlib. However, MSVC 2005 adds extensive support
for developing of 64bit applications and it looks like a natural
choice for 64bit Windows platform. So am +1 for supporting both MSVCs.
But I also would like to know if there are any other opinions.
2. You suggest using new ICU version 3.6. However, the version *3.4*
is currently used in the classlib. I don't like to say that version
3.4 is better than version 3.6. However, there is the neighbour thread
called "[general] Update to a new version of ICU" here in list. So IMO
we should finalize that discussion before moving to the version 3.6
Thanks,
2007/2/16, Ivan Zvolsky <i....@gmail.com>:
> Hello,
>
> Some time ago, I found out that Harmony is not buildable on Windows / x86_64
> (EM64T).
> I tried to reanimate at least the build which has required to update both
> classlib and drlvm build files, create stubs for some functions, etc.
>
> I've put my results (for now only classlib part) to HARMONY-3188.
> Could someone take a look? The comments are welcome.
>
> In particular, Geir might want to look at the first comment in the
> description :)
>
> Thanks,
> Ivan
>
--
Alexei Zakharov,
Intel ESSD
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 19, 2007, at 11:26 AM, Gregory Shimansky wrote:
> Ivan Zvolsky wrote:
>> I have also put my efforts with drlvm building to HARMONY-3196.
>> The patch
>> makes drlvm buildable on windows/em64t (and shouldn't break
>> building on
>> other platforms).
>> It still has some things to do, which I described in subtasks for
>> HARMONY-3196.
>
> I looked at the patches and I have a question. You've added amd64
> architecture in some select statements in the build along with
> em64t flag. I thought that from the build point they are
> equivalent, and build.arch property is defined in build.xml for all
> kinds of arch (x86_64, em64t, amd64) to be equal to "em64t". Why
> add another flag in build files?
And whatever the answer turns out to be, can we instead simply settle
on x86_64 please?
geir
>
>> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> Some time ago, I found out that Harmony is not buildable on
>>> Windows /
>>> x86_64 (EM64T).
>>> I tried to reanimate at least the build which has required to
>>> update both
>>> classlib and drlvm build files, create stubs for some functions,
>>> etc.
>>>
>>> I've put my results (for now only classlib part) to HARMONY-3188.
>>> Could someone take a look? The comments are welcome.
>>>
>>> In particular, Geir might want to look at the first comment in the
>>> description :)
>>>
>>> Thanks,
>>> Ivan
>>>
>>>
>>>
>
>
> --
> Gregory
>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Geir Magnusson Jr. wrote:
>
> On Feb 20, 2007, at 7:24 AM, Gregory Shimansky wrote:
>
>> Ivan Zvolsky wrote:
>>> On 2/19/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>>
>>>> Ivan Zvolsky wrote:
>>>> > I have also put my efforts with drlvm building to HARMONY-3196. The
>>>> patch
>>>> > makes drlvm buildable on windows/em64t (and shouldn't break
>>>> building on
>>>> > other platforms).
>>>> >
>>>> > It still has some things to do, which I described in subtasks for
>>>> > HARMONY-3196.
>>>>
>>>> I looked at the patches and I have a question. You've added amd64
>>>> architecture in some select statements in the build along with em64t
>>>> flag. I thought that from the build point they are equivalent, and
>>>> build.arch property is defined in build.xml for all kinds of arch
>>>> (x86_64, em64t, amd64) to be equal to "em64t". Why add another flag in
>>>> build files?
>>> I can't remember why I added this. But I just tried to modify all
>>> selects
>>> like "em64t,amd64" to simply "em64t" and the build worked fine. What
>>> is the
>>> best option to do:
>>> 1) should I replace drlvm_build_system.patch with newer version?
>>> 2) or add newer version without removing the old one?
>>> 3) or prepare a patch for drlvm_build_system.patch file?
>>
>> I'll take care about it myself. I'll remove all amd64 flags.
>> Converting em64t to x86_64 may be done later separately from enabling
>> x86_64 windows.
>
> If you are going to be doing it anyway, why not convert to "x86_64"?
I'll do it but I don't want to break things right now not to break
Ivan's patches. Also I would like to change no more than needed at a time.
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
On Feb 20, 2007, at 7:24 AM, Gregory Shimansky wrote:
> Ivan Zvolsky wrote:
>> On 2/19/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>>
>>> Ivan Zvolsky wrote:
>>> > I have also put my efforts with drlvm building to HARMONY-3196.
>>> The
>>> patch
>>> > makes drlvm buildable on windows/em64t (and shouldn't break
>>> building on
>>> > other platforms).
>>> >
>>> > It still has some things to do, which I described in subtasks for
>>> > HARMONY-3196.
>>>
>>> I looked at the patches and I have a question. You've added amd64
>>> architecture in some select statements in the build along with em64t
>>> flag. I thought that from the build point they are equivalent, and
>>> build.arch property is defined in build.xml for all kinds of arch
>>> (x86_64, em64t, amd64) to be equal to "em64t". Why add another
>>> flag in
>>> build files?
>> I can't remember why I added this. But I just tried to modify all
>> selects
>> like "em64t,amd64" to simply "em64t" and the build worked fine.
>> What is the
>> best option to do:
>> 1) should I replace drlvm_build_system.patch with newer version?
>> 2) or add newer version without removing the old one?
>> 3) or prepare a patch for drlvm_build_system.patch file?
>
> I'll take care about it myself. I'll remove all amd64 flags.
> Converting em64t to x86_64 may be done later separately from
> enabling x86_64 windows.
If you are going to be doing it anyway, why not convert to "x86_64"?
geir
>
>>> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>>> >>
>>> >> Hello,
>>> >>
>>> >> Some time ago, I found out that Harmony is not buildable on
>>> Windows /
>>> >> x86_64 (EM64T).
>>> >> I tried to reanimate at least the build which has required to
>>> update
>>> both
>>> >> classlib and drlvm build files, create stubs for some
>>> functions, etc.
>>> >>
>>> >> I've put my results (for now only classlib part) to HARMONY-3188.
>>> >> Could someone take a look? The comments are welcome.
>>> >>
>>> >> In particular, Geir might want to look at the first comment in
>>> the
>>> >> description :)
>>> >>
>>> >> Thanks,
>>> >> Ivan
>>> >>
>>> >>
>>> >>
>>> >
>>>
>>>
>>> --
>>> Gregory
>>>
>>>
>
>
> --
> Gregory
>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Ivan Zvolsky wrote:
> On 2/19/07, Gregory Shimansky <gs...@gmail.com> wrote:
>>
>> Ivan Zvolsky wrote:
>> > I have also put my efforts with drlvm building to HARMONY-3196. The
>> patch
>> > makes drlvm buildable on windows/em64t (and shouldn't break building on
>> > other platforms).
>> >
>> > It still has some things to do, which I described in subtasks for
>> > HARMONY-3196.
>>
>> I looked at the patches and I have a question. You've added amd64
>> architecture in some select statements in the build along with em64t
>> flag. I thought that from the build point they are equivalent, and
>> build.arch property is defined in build.xml for all kinds of arch
>> (x86_64, em64t, amd64) to be equal to "em64t". Why add another flag in
>> build files?
>
>
> I can't remember why I added this. But I just tried to modify all selects
> like "em64t,amd64" to simply "em64t" and the build worked fine. What is the
> best option to do:
> 1) should I replace drlvm_build_system.patch with newer version?
> 2) or add newer version without removing the old one?
> 3) or prepare a patch for drlvm_build_system.patch file?
I'll take care about it myself. I'll remove all amd64 flags. Converting
em64t to x86_64 may be done later separately from enabling x86_64 windows.
>> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>> >>
>> >> Hello,
>> >>
>> >> Some time ago, I found out that Harmony is not buildable on Windows /
>> >> x86_64 (EM64T).
>> >> I tried to reanimate at least the build which has required to update
>> both
>> >> classlib and drlvm build files, create stubs for some functions, etc.
>> >>
>> >> I've put my results (for now only classlib part) to HARMONY-3188.
>> >> Could someone take a look? The comments are welcome.
>> >>
>> >> In particular, Geir might want to look at the first comment in the
>> >> description :)
>> >>
>> >> Thanks,
>> >> Ivan
>> >>
>> >>
>> >>
>> >
>>
>>
>> --
>> Gregory
>>
>>
>
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by Ivan Zvolsky <i....@gmail.com>.
On 2/19/07, Gregory Shimansky <gs...@gmail.com> wrote:
>
> Ivan Zvolsky wrote:
> > I have also put my efforts with drlvm building to HARMONY-3196. The
> patch
> > makes drlvm buildable on windows/em64t (and shouldn't break building on
> > other platforms).
> >
> > It still has some things to do, which I described in subtasks for
> > HARMONY-3196.
>
> I looked at the patches and I have a question. You've added amd64
> architecture in some select statements in the build along with em64t
> flag. I thought that from the build point they are equivalent, and
> build.arch property is defined in build.xml for all kinds of arch
> (x86_64, em64t, amd64) to be equal to "em64t". Why add another flag in
> build files?
I can't remember why I added this. But I just tried to modify all selects
like "em64t,amd64" to simply "em64t" and the build worked fine. What is the
best option to do:
1) should I replace drlvm_build_system.patch with newer version?
2) or add newer version without removing the old one?
3) or prepare a patch for drlvm_build_system.patch file?
> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
> >>
> >> Hello,
> >>
> >> Some time ago, I found out that Harmony is not buildable on Windows /
> >> x86_64 (EM64T).
> >> I tried to reanimate at least the build which has required to update
> both
> >> classlib and drlvm build files, create stubs for some functions, etc.
> >>
> >> I've put my results (for now only classlib part) to HARMONY-3188.
> >> Could someone take a look? The comments are welcome.
> >>
> >> In particular, Geir might want to look at the first comment in the
> >> description :)
> >>
> >> Thanks,
> >> Ivan
> >>
> >>
> >>
> >
>
>
> --
> Gregory
>
>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Gregory Shimansky <gs...@gmail.com>.
Ivan Zvolsky wrote:
> I have also put my efforts with drlvm building to HARMONY-3196. The patch
> makes drlvm buildable on windows/em64t (and shouldn't break building on
> other platforms).
>
> It still has some things to do, which I described in subtasks for
> HARMONY-3196.
I looked at the patches and I have a question. You've added amd64
architecture in some select statements in the build along with em64t
flag. I thought that from the build point they are equivalent, and
build.arch property is defined in build.xml for all kinds of arch
(x86_64, em64t, amd64) to be equal to "em64t". Why add another flag in
build files?
> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>>
>> Hello,
>>
>> Some time ago, I found out that Harmony is not buildable on Windows /
>> x86_64 (EM64T).
>> I tried to reanimate at least the build which has required to update both
>> classlib and drlvm build files, create stubs for some functions, etc.
>>
>> I've put my results (for now only classlib part) to HARMONY-3188.
>> Could someone take a look? The comments are welcome.
>>
>> In particular, Geir might want to look at the first comment in the
>> description :)
>>
>> Thanks,
>> Ivan
>>
>>
>>
>
--
Gregory
Re: [general] Harmony enabling at Windows / x86_64
Posted by "Geir Magnusson Jr." <ge...@pobox.com>.
I wonder if I can run 64-bit windows in virtualization on the
mac.... it would be nice to have others besides you able to do this.
Does anyone else run this?
geir
On Feb 19, 2007, at 6:57 AM, Ivan Zvolsky wrote:
> I have also put my efforts with drlvm building to HARMONY-3196. The
> patch
> makes drlvm buildable on windows/em64t (and shouldn't break
> building on
> other platforms).
>
> It still has some things to do, which I described in subtasks for
> HARMONY-3196.
>
> Ivan.
>
> On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>>
>> Hello,
>>
>> Some time ago, I found out that Harmony is not buildable on Windows /
>> x86_64 (EM64T).
>> I tried to reanimate at least the build which has required to
>> update both
>> classlib and drlvm build files, create stubs for some functions, etc.
>>
>> I've put my results (for now only classlib part) to HARMONY-3188.
>> Could someone take a look? The comments are welcome.
>>
>> In particular, Geir might want to look at the first comment in the
>> description :)
>>
>> Thanks,
>> Ivan
>>
>>
>>
Re: [general] Harmony enabling at Windows / x86_64
Posted by Ivan Zvolsky <i....@gmail.com>.
I have also put my efforts with drlvm building to HARMONY-3196. The patch
makes drlvm buildable on windows/em64t (and shouldn't break building on
other platforms).
It still has some things to do, which I described in subtasks for
HARMONY-3196.
Ivan.
On 2/16/07, Ivan Zvolsky <i....@gmail.com> wrote:
>
> Hello,
>
> Some time ago, I found out that Harmony is not buildable on Windows /
> x86_64 (EM64T).
> I tried to reanimate at least the build which has required to update both
> classlib and drlvm build files, create stubs for some functions, etc.
>
> I've put my results (for now only classlib part) to HARMONY-3188.
> Could someone take a look? The comments are welcome.
>
> In particular, Geir might want to look at the first comment in the
> description :)
>
> Thanks,
> Ivan
>
>
>