g compiler.
Looking into toolchain.m4, this sounds fair to me, as the BuildC compiler
(line 916 and below) is also tested
with TOOLCHAIN_EXTRACT_COMPILER_VERSION(BUILD_CC, [BuildC]) which
unconditionally checks for the $TOOLCHAIN_TYPE.
Hence, it seems cross-compiling using a clang compiler, while using
ested
with TOOLCHAIN_EXTRACT_COMPILER_VERSION(BUILD_CC, [BuildC]) which
unconditionally checks for the $TOOLCHAIN_TYPE.
Hence, it seems cross-compiling using a clang compiler, while using gcc as
the build compiler is not possible.
That's by no means a showstopper to me, I just want to double che
> @@ -71,7 +78,7 @@
> >>>>>>define generate-preproc-src
> >>>>>> $(call MakeDir, $(@D))
> >>>>>> ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
> >>>>>> - $(CPP) $(CP
y
changed in buildjdk-spec.gmk.in:
http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main
issue
is that when cross compiling, and creating a buildjdk during th
($(GREP) -v '^$(&2) \
> > >>> | $(NAWK) '/@@START_HERE@@/,0' \
> > >>> | $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> > >>> FILE - DO NOT EDIT/' \
> > >>>
> > >>>
>
t; >>> | $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
> >>> FILE - DO NOT EDIT/' \
> >>>
> >>>
> >>> Cheers,
> >>> Ao Qi
> >>>
> >>> On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson
&
ildjdk-spec.gmk.in:
http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main
issue
is that when cross compiling, and creating a buildjdk during the
build,
the Uni
d. This variable
also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
changed in buildjdk-spec.gmk.in:
http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1
17739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the t
ik:
> >
> > Looks good.
> >
> > Tim
> >
> >> This is a fix for a problem brought up on this list [1]. The main issue
> >> is that when cross compiling, and creating a buildjdk during the build,
> >> the UnixConstants.java cannot necessarily be r
buildjdk-spec.gmk.in. New webrev, only
changed in buildjdk-spec.gmk.in:
http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and
changed in buildjdk-spec.gmk.in:
http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
/Erik
On 2019-06-04 07:53, Tim Bell wrote:
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build
Erik:
Looks good.
Tim
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came
This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came to the conclusion
that
/Main.gmk:441: recipe for target 'generate-link-opt-data' failed
> > make[2]: *** [generate-link-opt-data] Error 2
>
> This should have worked, but sounds like something that can typically
> fail when cross-compiling. As a workaround, disable class list
> generation: &q
Hi John,
On Fri, Jan 25, 2019 at 11:10 PM Ao Qi wrote:
>
> On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz
> wrote:
> >
> > On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue,
> > below is some sctripts I used
> > > to cross compile a mips zero jdk, which can tri
On Fri, Jan 25, 2019 at 10:51 PM John Paul Adrian Glaubitz
wrote:
>
> On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue,
> below is some sctripts I used
> > to cross compile a mips zero jdk, which can trigger the bug.
>
> Native builds on Debian unstable on mips* work?
>
Wo
Hi,
On Fri, Jan 25, 2019 at 10:31 PM John Paul Adrian Glaubitz
wrote:
>
> Hi!
>
> On 1/24/19 3:28 AM, Leslie Zhai wrote:
> > Please give me some advice about how to fix the root cause, thanks a lot!
>
> Just as a heads-up: In Debian we have two patches required for OpenJDK on the
> mips
> target
On 1/25/19 3:44 PM, Ao Qi wrote:> FYI, if one wants to debug this issue, below
is some sctripts I used
> to cross compile a mips zero jdk, which can trigger the bug.
Native builds on Debian unstable on mips* work?
> do one patch [1] then make images
What about the alignment patch? Is that still
,
> >>>>>>
> >>>>>> I'm not Erik :) however
> >>>>>>
> >>>>>> On 24/01/2019 12:28 pm, Leslie Zhai wrote:
> >>>>>>> Hi Erik,
> >>>>>>>
> >
Hi!
On 1/24/19 3:28 AM, Leslie Zhai wrote:
> Please give me some advice about how to fix the root cause, thanks a lot!
Just as a heads-up: In Debian we have two patches required for OpenJDK on the
mips
targets:
> https://git.launchpad.net/~openjdk/ubuntu/+source/openjdk/+git/openjdk/tree/debian
ux-mips64el-normal-server-fastdebug/support/link_opt/classlist'
make/Main.gmk:441: recipe for target 'generate-link-opt-data' failed
make[2]: *** [generate-link-opt-data] Error 2
This should have worked, but sounds like something that can typically
fail when cross-compiling. As a work
,
Because the flags' macro of MIPS is different from other
targets[1], it
will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template,
for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is
different
from other targets. Then failed[2] to
avid Holmes
wrote:
Hi Leslie,
I'm not Erik :) however
On 24/01/2019 12:28 pm, Leslie Zhai wrote:
Hi Erik,
Because the flags' macro of MIPS is different from other
targets[1], it
will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java
:
Hi Erik,
Because the flags' macro of MIPS is different from other
targets[1], it
will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template,
for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is
different
from other targets. Then fai
the `Flags` in `FileChannel` is
different
from other targets. Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].
It's been quite a while since we built for a platform where the flags
had different values, but it is supposed to work. I suspec
from other targets. Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].
It's been quite a while since we built for a platform where the flags
had different values, but it is supposed to work. I suspect that
the way
we build now with the mo
erent from other
targets[1], it
will effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different
from other targets. Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu
effect the `UnixConstants` of
src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different
from other targets. Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].
It's bee
[1], it
> > will effect the `UnixConstants` of
> > src/java.base/unix/classes/sun/nio/fs/UnixConstants.java.template, for
> > example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different
> > from other targets. Then failed[2] to cross compiling jdk12 for
> > mips64e
Hi David,
Thanks for your kind response!
You point out the root cause: executing a tool on the build platform
(X86 host) using the newly compiled classes for the target platform
(MIPS target) especially when the flags' macro is different.
I will use workaround 1 before fix the root cause.
R
r
example, PREFIX_O_APPEND, so the `Flags` in `FileChannel` is different
from other targets. Then failed[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].
It's been quite a while since we built for a platform where the flags
had different values, but it is supp
led[2] to cross compiling jdk12 for
mips64el-linux-gnu target by following the document[3].
Workaround 1:
Only make hotspot, then scp
build/linux-mips64el-normal-server-fastdebug/jdk/lib/server/libjvm.so to
mips64el target machine, java version is able to work[4], but it needs
to make imag
> On May 21, 2016, at 5:41 AM, Erik Joelsson wrote:
>
> We recently enabled a couple of cross compilation configurations in the main
> PIT builds. These builds run bootcycle builds. The boot cycle build can
> naturally not work when cross compiling, but the makefiles ar
naturally not work when cross compiling, but the
makefiles are currently not equipped to handle that.
Bug: https://bugs.openjdk.java.net/browse/JDK-8157506
Patch:
diff -r fa3dec0c2862 make/Main.gmk
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -302,9 +302,13 @@
BOOTCYCLE_TARGET := product-images
Looks okay to me.
On 21/05/2016 13:41, Erik Joelsson wrote:
We recently enabled a couple of cross compilation configurations in
the main PIT builds. These builds run bootcycle builds. The boot cycle
build can naturally not work when cross compiling, but the makefiles
are currently not
We recently enabled a couple of cross compilation configurations in the
main PIT builds. These builds run bootcycle builds. The boot cycle build
can naturally not work when cross compiling, but the makefiles are
currently not equipped to handle that.
Bug: https://bugs.openjdk.java.net/browse
ing on Ubuntu 12.10. So we
know, or already assume, that the value selected when compiling for
linux_x86 will be valid when running on all linux_x86 platforms. This
situation is the same regardless of platform, and regardless of if we're
cross-compiling or not. And we also does not expect thes
, or already assume, that the value selected when compiling for
linux_x86 will be valid when running on all linux_x86 platforms. This
situation is the same regardless of platform, and regardless of if we're
cross-compiling or not. And we also does not expect these values to
change as long as w
extracting system constants, that might be a good idea, yes. I
can't see any reason for why not a cross-compiling toolchain's
preprocessor could be used in those cases, so that should be one way to
get rid of the build compiler. Thanks for the suggestion!
/Magnus
Hi Magnus,
On 4/02/2014 12:13 AM, Magnus Ihse Bursie wrote:
I just noticed this when replying to a mail to Volker, but I think this
is worth a thread on it's own.
There are three very similar build helpers that are compiler with
BUILD_CC, i.e. the compiler for the build (not target) platform. T
I just noticed this when replying to a mail to Volker, but I think this
is worth a thread on it's own.
There are three very similar build helpers that are compiler with
BUILD_CC, i.e. the compiler for the build (not target) platform. They are:
jdk/src/solaris/native/sun/nio/fs/genUnixConstant
Hi Erik:
New webrev for this:
http://cr.openjdk.java.net/~erikj/8005855/webrev.root.02/
I changed the sed to only remove the -R argument and made it
conditional on cross compilation.
Looks good. Thanks for the background!
Tim
A bit of background on this. The X_LIBS variable is created b
Okay. I can't attest to the accuracy of the sed command but I agree with
the intent :) Though I'm not sure there still exists any place where we
use X_LIBS if cross-compiling.
Thanks,
David
On 22/01/2013 8:18 PM, Erik Joelsson wrote:
New webrev for this:
http://cr.openjdk.java.
New webrev for this:
http://cr.openjdk.java.net/~erikj/8005855/webrev.root.02/
I changed the sed to only remove the -R argument and made it conditional
on cross compilation.
A bit of background on this. The X_LIBS variable is created by autoconf
by calling some special macros to locate libra
8003958 fixes this for sizer generation yes, but there is also one
library in CompileNativeLibraries that has X_LIBS on the link line. But
I suppose we shouldn't fix it unless there is a problem with it.
/Erik
On 2013-01-09 03:56, David Holmes wrote:
On 9/01/2013 5:56 AM, Kelly O'Hair wrote:
On 9/01/2013 5:56 AM, Kelly O'Hair wrote:
I need more info on this, what is X_LIBS for, and why remove ALL -R options.
IIRC Fredrik added this to deal with some binary difference detected on
OSX. I don't know what these variables actually contain
I always considered the -R options to be LD
I need more info on this, what is X_LIBS for, and why remove ALL -R options.
I always considered the -R options to be LD options, not library specifications
really.
The -L and -l options are library specifications, but -R is just a path that
gets baked into the .so
for runtime access to the libr
Hi Erik:
Filter away -R flags from X_LIBS variable in configure.
http://cr.openjdk.java.net/~erikj/8005855/webrev.root.01/
common/autoconf/libraries.m4:
143 X_LIBS=`$ECHO $X_LIBS | $SED 's/-R.*//g'`
If I am reading this correctly, sed will delete everything from -R to
end of line. Is that
Filter away -R flags from X_LIBS variable in configure.
http://cr.openjdk.java.net/~erikj/8005855/webrev.root.01/
OBJCOPY changes look good.
bill
On 11/4/2012 5:32 PM, David Holmes wrote:
Okay here's the final update :)
http://cr.openjdk.java.net/~dholmes/8002034/webrev.03/
We now have a default objcopy when cross-compiling and I augmented the
error message if no objcopy is found. These changes
INFO: ENABLE_FULL_DEBUG_SYMBOLS=0
Thanks,
David
-Dmitry
On 2012-11-02 02:15, David Holmes wrote:
Thanks for the review Dmitry.
On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
David,s
if we use host /usr/bin/objcopy for cross compiling,
changes looks good for me.
??? We don't use host /usr/bin/objcopy
Debug Symbols when cross-compiling
>>>>
>>>> The initial FDS work simply disables FDS when cross-compilation is
>>>> involved. But we're now ready to deal with the cross-compilation case
>>>> (and even if we weren't these changes would be fi
excludes a couple of the unnecessary
> executions.
>
> Thanks,
> David
>
> On 31/10/2012 5:29 PM, David Holmes wrote:
>> http://cr.openjdk.java.net/~dholmes/8002034/webrev/
>>
>> This mainly addresses
>>
>> JDK-8002034 Allow Full Debug Sy
Changeset: 3717bcf9d7a7
Author:dholmes
Date: 2012-11-07 23:12 -0500
URL: http://hg.openjdk.java.net/jdk8/build/jdk/rev/3717bcf9d7a7
8002040: Allow Full Debug Symbols when cross-compiling
Reviewed-by: dcubed, erikj, tbell
! make/common/Defs-linux.gmk
On 11/06/12 21:08, David Holmes wrote:
webrev:
http://cr.openjdk.java.net/~dholmes/8002040/webrev/
This is a simplified variant of the change just made to Hotspot.
Instead of disabling FDS when cross-compiling we change the default
location of objcopy, and just as with native compilation
On 11/6/12 10:08 PM, David Holmes wrote:
webrev:
http://cr.openjdk.java.net/~dholmes/8002040/webrev/
Thumbs up.
make/common/Defs-linux.gmk
No comments.
This is a simplified variant of the change just made to Hotspot.
Instead of disabling FDS when cross-compiling we change the default
Looks good to me.
/Erik
On 2012-11-07 06:08, David Holmes wrote:
webrev:
http://cr.openjdk.java.net/~dholmes/8002040/webrev/
This is a simplified variant of the change just made to Hotspot.
Instead of disabling FDS when cross-compiling we change the default
location of objcopy, and just as
webrev:
http://cr.openjdk.java.net/~dholmes/8002040/webrev/
This is a simplified variant of the change just made to Hotspot. Instead
of disabling FDS when cross-compiling we change the default location of
objcopy, and just as with native compilation either the default objcopy
is found or we
ws/makefiles/defs.make
nit line 135: space between 'times.We'
Dan
We now have a default objcopy when cross-compiling and I augmented the
error message if no objcopy is found. These changes only affect the
linux defs.make.
Thanks,
David
On 2/11/2012 12:39 PM, David Holmes wrote:
O
at end of sentence.
make/linux/makefiles/vm.make
nit line 359: added extra blank line
make/solaris/makefiles/defs.make
nit line 113: space between 'times.We'
make/windows/makefiles/defs.make
nit line 135: space between 'times.We'
Dan
We now have a default obj
David,
Looks good for me.
-Dmitry
On 2012-11-05 02:32, David Holmes wrote:
> Okay here's the final update :)
>
> http://cr.openjdk.java.net/~dholmes/8002034/webrev.03/
>
> We now have a default objcopy when cross-compiling and I augmented the
> error message if no
Best version so far.
/Erik
On 2012-11-04 23:32, David Holmes wrote:
Okay here's the final update :)
http://cr.openjdk.java.net/~dholmes/8002034/webrev.03/
We now have a default objcopy when cross-compiling and I augmented the
error message if no objcopy is found. These changes only a
Okay here's the final update :)
http://cr.openjdk.java.net/~dholmes/8002034/webrev.03/
We now have a default objcopy when cross-compiling and I augmented the
error message if no objcopy is found. These changes only affect the
linux defs.make.
Thanks,
David
On 2/11/2012 12:39 PM,
there any defaults?
No. The makefiles know nothing about the toolsets for cross-compiling.
We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
tools, why not go for OBJCOPY as well? It may or may not exist. Is that
worse than the current situation?
Fair point, we could just
Sorry, (my eyes) I misread if
>>>>>>
>>>>>> As far as I understand, cross compilation require explicit
>>>>>> ALT_OBJCOPY.
>>>>>
>>>>> Yes.
>>>>>
>>>>>> Is there any defaults?
gt;> As far as I understand, cross compilation require explicit ALT_OBJCOPY.
>>>
>>> Yes.
>>>
>>>> Is there any defaults?
>>>
>>> No. The makefiles know nothing about the toolsets for cross-compiling.
>> We set CC, CPP, CXX using
know nothing about the toolsets for cross-compiling.
We set CC, CPP, CXX using COMPILER_PATH which gets us to the cross
tools, why not go for OBJCOPY as well? It may or may not exist. Is that
worse than the current situation?
Fair point, we could just assume that when cross-compiling we find
On 2/11/2012 8:49 AM, Dmitry Samersoff wrote:
David,
Sorry, (my eyes) I misread if
As far as I understand, cross compilation require explicit ALT_OBJCOPY.
Yes.
Is there any defaults?
No. The makefiles know nothing about the toolsets for cross-compiling.
Does it make sense to warn if
/2012 10:02 PM, Dmitry Samersoff wrote:
>> David,s
>>
>> if we use host /usr/bin/objcopy for cross compiling,
>> changes looks good for me.
>
> ??? We don't use host /usr/bin/objcopy for cross-compiling that is why
> DEF_OBJCOPY is only set when not cross-co
va.net/~dholmes/8002034/webrev/
This mainly addresses
JDK-8002034 Allow Full Debug Symbols when cross-compiling
The initial FDS work simply disables FDS when cross-compilation is
involved. But we're now ready to deal with the cross-compilation case
(and even if we weren't these changes would b
Thanks for the review Dmitry.
On 1/11/2012 10:02 PM, Dmitry Samersoff wrote:
David,
if we use host /usr/bin/objcopy for cross compiling,
changes looks good for me.
??? We don't use host /usr/bin/objcopy for cross-compiling that is why
DEF_OBJCOPY is only set when not cross-compiling.
id Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8002034/webrev/
This mainly addresses
JDK-8002034 Allow Full Debug Symbols when cross-compiling
The initial FDS work simply disables FDS when cross-compilation is
involved. But we're now ready to deal with the cross-compilation case
(an
David,
if we use host /usr/bin/objcopy for cross compiling,
changes looks good for me.
-Dmitry
On 2012-11-01 07:41, David Holmes wrote:
> No takers so far - don't be shy, it's not a difficult one I promise :)
>
> Updated webrev: http://cr.openjdk.java.net/~dholme
excludes a couple of the
unnecessary executions.
Thanks,
David
On 31/10/2012 5:29 PM, David Holmes wrote:
http://cr.openjdk.java.net/~dholmes/8002034/webrev/
This mainly addresses
JDK-8002034 Allow Full Debug Symbols when cross-compiling
The initial FDS work simply disables FDS when cross-comp
ote:
http://cr.openjdk.java.net/~dholmes/8002034/webrev/
This mainly addresses
JDK-8002034 Allow Full Debug Symbols when cross-compiling
The initial FDS work simply disables FDS when cross-compilation is
involved. But we're now ready to deal with the cross-compilation case
(and even if we weren't
http://cr.openjdk.java.net/~dholmes/8002034/webrev/
This mainly addresses
JDK-8002034 Allow Full Debug Symbols when cross-compiling
The initial FDS work simply disables FDS when cross-compilation is
involved. But we're now ready to deal with the cross-compilation case
(and even if we we
On 9/03/2012 9:20 AM, David Holmes wrote:
On 9/03/2012 3:40 AM, martin burtscher wrote:
can anybody confirm, that cross compiling is working with make flags:
CROSS_COMPILE_ARCH
ALT_COMPILER_PATH?
With confirm i mean tested and not just read in readme, because theres
also a BUILD_HEADLESS_ONLY
Martin,
On 9/03/2012 3:40 AM, martin burtscher wrote:
Hello,
can anybody confirm, that cross compiling is working with make flags:
CROSS_COMPILE_ARCH
ALT_COMPILER_PATH?
With confirm i mean tested and not just read in readme, because theres
also a BUILD_HEADLESS_ONLY in the readme which
Hello,
can anybody confirm, that cross compiling is working with make flags:
CROSS_COMPILE_ARCH
ALT_COMPILER_PATH?
With confirm i mean tested and not just read in readme, because theres also
a BUILD_HEADLESS_ONLY in the readme which doesn't work.
Thanks.
Martin
Hi,
Thank you guys for your info.
I will try to do what Christian said. Hope it works.
Anyways if it does not work correctly then, it cannot be cross compiled I
guess.
Thanks a lot.
Regards,
Deepak
On Mon, Dec 7, 2009 at 3:55 PM, Erik Trimble wrote:
> Christian Thalinger wrote:
>
>> On Mon,
Christian Thalinger wrote:
On Mon, 2009-12-07 at 10:39 +0100, Christian Thalinger wrote:
There problem here is ADLC, which is part of the server compiler. Let
me try to get it built for a 32-bit host...
A really ugly (but possibly working) hack to build a full OpenJDK
successfully wou
On Mon, 2009-12-07 at 10:39 +0100, Christian Thalinger wrote:
> There problem here is ADLC, which is part of the server compiler. Let
> me try to get it built for a 32-bit host...
A really ugly (but possibly working) hack to build a full OpenJDK
successfully would be to copy a 32-bit adlc over th
On Mon, 2009-12-07 at 14:55 +0530, Deepak Mathews wrote:
> 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 compilation impossible?
>
>
> What about cross compiling for MI
model = x86_64
os_arch = linux_x86
os_arch_model = linux_x86_64
lib_arch = amd64
otherwise they will be determined from the properties of the build machine.
I don't know if anyone has tried this, but it is where I would start.
Note that building 32-bit on 64-bit is not truly cross-compili
which will make cross
compilation impossible?
What about cross compiling for MIPS or PPC from the same 32 bit host? Will
this same VM problem be there for that also?
Thanks.
Deepak
On Mon, Dec 7, 2009 at 2:35 PM, Vikram A wrote:
> hi Deepak,
>
> Incomplete information, please also s
resending- adding the alias.
On Mon, Dec 7, 2009 at 2:35 PM, Vikram A 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
Hi,
Thank you Eric, for your quick reply.
Sorry, I had forgot to mention the platform.
It is Linux.
Thanks.
Deepak
On Mon, Dec 7, 2009 at 12:16 PM, Erik Trimble wrote:
> Deepak Mathews wrote:
>
>> Hi,
>>
>> I am trying to cross compile for x86 64 bit from a x86 32 bit host
>> machine.
>>
>>
Deepak Mathews wrote:
Hi,
I am trying to cross compile for x86 64 bit from a x86 32 bit host
machine.
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.
Hi,
I am trying to cross compile for x86 64 bit from a x86 32 bit host machine.
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
90 matches
Mail list logo
