Cross Compiling for x86_64 on x86
deepak2427 at gmail.com
Mon Dec 7 09:25:20 UTC 2009
Vikram and Erik,
Thank you so much for your info.
I will give the details.
$ uname -a
Linux 2.6.9-34.ELsmp #1 SMP Fri Feb 24 16:54:53 EST 2006 i686 i686 i386
$ cat /etc/redhat-release
Red Hat Enterprise Linux AS release 4 (Nahant Update 3)
I am new to this and have some doubts. It might be a bit trivial.
By hotspot due you mean the same as the VM used for building OpenJDK?
I had compiled 32 bit target on 64 bit host machine without any problems.
>> I haven't yet heard of building a 64 bit VM on a 32 bit, the other way
might still be ok.
My guess is a 64 bit VM will not be able to load correctly on 32 a bit
machine. Copying the libjvm.so will not help, in that case.
So is it not possible to build OpenJDK 64 bit on a 32 bit host?
Can the building of OpenJDK made independant of the host machine. Or does it
run some programs which are dependant (like adlc) which will make cross
What about cross compiling for MIPS or PPC from the same 32 bit host? Will
this same VM problem be there for that also?
On Mon, Dec 7, 2009 at 2:35 PM, Vikram A <vikram.account at gmail.com> wrote:
> hi Deepak,
> Incomplete information, please also specify the workspace you are trying to
> build. Also, please share the errors generated.
> Putting uname -a in the first mail itself helps alongwith appropriate cat
> e.g cat /etc/redhat-release
> I guess it is hotspot in this case, in which case the following would be
> Let me try to put some points which might be useful.
> (Of course, if you see differences in Erik's comments from mine, he is the
> final authority.)
> 1. I haven't yet heard of building a 64 bit VM on a 32 bit, the other way
> might still be ok.
> My guess is a 64 bit VM will not be able to load correctly on 32 a bit
> machine. Copying the libjvm.so will not help, in that case.
> It might just see a reference and proceed, but end up loading the 32 bit
> 2. If you are trying to build on a different kind of machine (crossing the
> vm bit length and the machine bit length) and not specifying the ARCH_MODEL
> explicitly, please try to do so.
> This may give out errors correctly.
> 3. Also as a side note, a 32 bit build should not require link to 64 bit
> JVM even as a ALT_BOOTDIR.
> but a 64 bit VM would require atleast 4 libjvm.so.
> 32 bit libjvm.so
> 32 bit libjvm_g.so
> 64 bit libjvm.so
> 64 bit libjvm_g.so
> The 64 bit VM does not run on its own, it required a support of 32 bit vm
> as well.
> It will work something like the last line in pt 1 above.
> 4. >>an adlc utility is run during the compilation, which is of 64 bit, so
> cannot be executed on >>the host machine.
> Goes back to pt 1. Yes, adlc is architecture dependant and will not run on
> 32 bit.
> Like I mentioned above the other way, (build 32 bit on a 64 bit ) would
> probably be ok.
> On Mon, Dec 7, 2009 at 12:45 PM, Deepak Mathews <deepak2427 at gmail.com>wrote:
>> Thank you Eric, for your quick reply.
>> Sorry, I had forgot to mention the platform.
>> It is Linux.
>> On Mon, Dec 7, 2009 at 12:16 PM, Erik Trimble <Erik.Trimble at sun.com>wrote:
>>> Deepak Mathews wrote:
>>>> I am trying to cross compile for x86 64 bit from a x86 32 bit host
>>>> I am facing a lot of issues in this regard.
>>>> Has anyone been able to successfully do this.
>>>> Why is the target being linked against libjvm.so which is in the
>>>> ALT_BOOTDIR on the host system.
>>>> Even if i fix that issue by copying libjvm.so from a 64bit JDK, an adlc
>>>> utility is run during the compilation, which is of 64 bit, so cannot be
>>>> executed on the host machine.
>>> First off, which platform? Windows? Linux? Solaris?
>>> Frankly, I don't think we've ever tried doing Windows 64-bit on a 32-bit
>>> platform, and I can't imagine it would really be easy at all.
>>> Erik Trimble
>>> Java System Support
>>> Mailstop: usca22-123
>>> Phone: x17195
>>> Santa Clara, CA
>>> Timezone: US/Pacific (GMT-0800)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the build-dev