harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sergey Dmitriev" <sergey.v.dmitr...@gmail.com>
Subject Re: [drlvm] Supporting more platforms
Date Fri, 18 May 2007 11:17:54 GMT
Yep, exactly. Sorry for the confusion if any.
Ant's os.arch is actually System.getProperty("os.arch") not underlying
arch - x86_64 jre gives "x86_64" (or equivalent), x86 jre gives "x86"
(or equivalent). So you're right: as long as we build x86 drlvm with
x86 jdk and x86_64 drlvm with x86_64 jdk - MACHINE_ARCH and stuff is
redundant.

Sergey

On 5/18/07, Vladimir Ivanov <ivavladimir@gmail.com> wrote:
> On 5/18/07, Sergey Dmitriev <sergey.v.dmitriev@gmail.com> wrote:
> > Guys
> >
> > > > Can we remove the env.MACHINE_ARCH variable and just use os.arch (as
> > > > classlib does)?  Or is this a workaround for people building x86_64 with
> > > > an ia32 jvm?
> > > I've never seen it used, but anyway those people can directly override
> > > "os.arch" (AFAIS "build.arch" it's name in drlvm build system ;) ). So
> > > +1 to remove.
> >
>
> > As for the MACHINE_ARCH... That was introduced knowingly just because
> > unfortunately Ant's os.arch does not distinguish x86_64 and x86
> > platforms. That is why on linux in build.sh we use:
> >  MACHINE_ARCH=`uname -m`
>
> As I know to correctly define x86_64 arch the ant should be run on 64-bit java.
> Please, try it.
>
>  thanks, Vladimir
>
> >
> > As for the subject of the letter as a whole - Mark, I like you're
> > looking at macosx/ppc32. Thats for sure! :)
> >
> >
> > Thanks
> > Sergey
> >
> >
> > On 5/18/07, Alexey Varlamov <alexey.v.varlamov@gmail.com> wrote:
> > > Mark,
> > > It's really nice to see you finally approaching drlvm! :)
> > > More inlined...
> > >
> > > 2007/5/18, Mark Hindess <mark.hindess@googlemail.com>:
> > > >
> > > > I'm looking at what would need to be changed in drlvm to support more
> > > > platforms.  (Specifically, I'm looking at macosx/ppc32 and I'll probably
> > > > look at freebsd/x86 and maybe freebsd/x86_64.)  I thought I'd mention
> > > > some of the issues I've found so far regarding changes I plan to make
> > > > just to see if I'm taking a reasonable approach.
> > > >
> > > > There are at least three locations that set up os/arch variables:
> > > >
> > > >  build/make/build.xml setup.xml targets/ehwa.test.xml
> > > >
> > > > For now, I'm just going to update all three, but really we need to
> > > > figure out how to reconcile these.  (Ideally, we should reconcile them
> > > > along with the classlib logic just as we need to figure out how to
> > > > reconcile the shared dependencies.)
> > > Yes, ultimately all top-levevl projects should use a shared setup (aka
> > > properties.xml) and dependencies.
> > >
> > > >
> > > > I plan to add an if.unix property (or three ;-). Similarly, I plan to
> > > > add an osfamily variable for use in the <select /> tags.  Ultimately,
> > > > some of the directories called 'linux' might want to be renamed 'unix'
> > > > but I'll tackle that after I've seen what code is likely to be common.
> > > Agreed.
> > >
> > > > Is the ant variable vm.port.includes defined anywhere?  (I spotted
> > > > ${vm.port.includes} in verbose logs and just wondered if this was
> > > > intentional?)
> > >
> > > This must be overlooked piece spread through copy-paste, just remove it.
> > >
> > > > Can we remove the env.MACHINE_ARCH variable and just use os.arch (as
> > > > classlib does)?  Or is this a workaround for people building x86_64 with
> > > > an ia32 jvm?
> > > I've never seen it used, but anyway those people can directly override
> > > "os.arch" (AFAIS "build.arch" it's name in drlvm build system ;) ). So
> > > +1 to remove.
> > >
> > > >
> > > > Quite a few files contain #include <malloc.h> but the linux/freebsd/osx
> > > > man page for malloc(3) says it should be #include <stdlib.h>.  I
seem
> > > > to recall making this change in classlib code at some point, but will
> > > > fixing this in drlvm break anything?  Windows?
> > >
> > > Most invokations of malloc in DRLVM are wrapped via macros defined in
> > > port_malloc.h. I see <malloc.h> directly included only in jitrino and
> > > portlib sources. The first was not fully moved to using portlib for
> > > historical reasons, feel free to fix.
> > > And the last may be fixed to consistently use port_malloc.h as well.
> > >
> > > > I'll probably start making changes over the weekend.  Once I've made the
> > > > basic build system changes then I guess I'll start looking at porting
> > > > the actual code.
> > > Cool! And all good luck to you ;)
> > >
> > > WBR,
> > > Alexey
> > >
> > > >
> > > > Regards,
> > > >  Mark.
> > > >
> > > >
> > > >
> > >
> >
>

Mime
View raw message