On Jan 23, 2007, at 12:00 PM, Gregory Shimansky wrote:
Geir Magnusson Jr. wrote:
+1
(I thought we'd agreed on this - there were a few remaining cases,
I thought.)
I've grepped the sources and found very many places with em64t in
DRLVM and quite many of amd64 in classlib. I think I'll try to
clean the sources and build system completely of mentioning vendor
specific identifiers, so that all functions, interfaces and
constants could be reused in easily in any other code.
I meant in meaningful functional places where there would be external
visibility or behavior. I'll take a look too.
geir
(and I thought that "em64t" was intel shorthand for what AMD calls
"amd64" which is "x86_64")
Yes it is true.
On Jan 23, 2007, at 8:10 AM, Gregory Shimansky wrote:
Hello
Today while investigating the bug in HARMONY-2975 it appeared
that eclipse doesn't start on 64-bit Linux because os.arch
property value is em64t. The property is set in DRLVM source.
Eclipse doesn't recognize this architecture and failed to load
SWT library. When this property value is changed to x86_64
Eclipse runs ok.
I think we should agree how to call 64-bit platform and I think
it is better to follow the same convention as is used in Linux,
that is call it x86_64 [1].
It may happen that for better compatibility or reuse of VM and
classlib code in other projects we'll need to change some other
em64t and amd64 mentions in the sources to x86_64. If there is no
strong objection I would like to change all sources to use only
x86_64 instead of brand names, and rename the files which contain
em64t in their names. What do you think?
[1] http://en.wikipedia.org/wiki/EM64T#Industry_naming_conventions
--Gregory
--
Gregory
