how to build 32-bit openjdk7 on x86_64
bccheng at google.com
Wed Nov 28 20:39:18 UTC 2007
On Nov 28, 2007 10:47 AM, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> From earlier emails... it appears you are trying to build 32bit on a
> 64bit machine?
Yes, we are doing cross builds on 64-bit machines for 32-bit binaries.
> In general we don't do that, or haven't.
> For us, Linux 32bit builds are done on 32bit machines, 64bit on 64bit
> Mostly because our official build systems are completely different Linux's
> for 32 and 64.
> If your adventure is to figure out how to build 32bit on a 64bit system,
> please keep track
> of what you had to do and we can document it, and have fun. ;^)
After enumerating in86, I think I have found the magic ARCH value for
cross builds - i586. It is accepted by corba and jli and other modules with
minimal patches. I am currently verifying the minimal number of changes to
make it work.
> Other than makefile changes... (the ARCH sistuation is tricky)...
> I know that you need some 32bit static libraries installed on your 64bit
> system (ones that are not installed by default).
> Kelly O'Hair wrote:
> > I recall a problem where if you have an env variable named ARCH, you
> > will impact the build of hotspot. I forget all the details, but I recall
> > that some of the hotspot makefiles do an 'ifndef ARCH' before setting
> > so it can get impacted by the environment variables.
> > The ARCH_DATA_MODEL=32 or ARCH_DATA_MODEL=64 is used by the openjdk
> > makefiles
> > (hotspot makefiles may also look for LP64=1).
> > I would try running 'make sanity' and see what ARCH setting it has.
> > The whole arch naming issue is a bit messy. There is a libarch name used
> > under
> > the 'lib' directory, I call this LIBARCH and for Solaris and Linux it's
> > one of
> > i386, sparc, amd64, or sparcv9. (Linux may use sparc64???)
> > Windows doesn't really use a LIBARCH.
> > Then there is the ARCH used after the PLATFORM name of windows, linux,
> > solaris
> > to create the directory names and bundles, like windows-i586 (yes, it's
> > i586
> > in this case, or sparc or amd64 or sparcv9).
> > Then there are other places where people have used generic arch names
> > x86 or x64.
> > My advice is to not mess with ARCH and not set ARCH in your environment.
> > If the makefiles aren't figuring out what the correct ARCH is, then we
> > should
> > fix that. I'm not sure when this ARCH mess will ever be cleaned up, but
> > the first step may be to stop using the spelling "ARCH" in the makefiles
> > because of the confusion as to where it's used and what it means.
> > (Getting ARCH from the environment variables also seems very wrong to
> > ---
> > The ALT_JDK_IMPORT_PATH problem is a known one, setting it to the boot
> > jdk is
> > harmless when doing a full build.
> > -kto
> > Ben Cheng wrote:
> >> Hi Folks,
> >> I am trying to build 32-bit openjdk7 from source under control/make,
> >> but I seem to have endless troubles picking up the right ARCH option.
> >> The source code is from the b23 snapshot.
> >> I started with
> >> make ARCH_DATA_MODEL=32 ALT_BOOTDIR=/usr/lib/jvm/java-6-sun
> >> ANT_HOME=<my_ant_path> FINDBUGS_HOME=<my_findbugs_path>
> >> It quickly failed with the following error:
> >> [ gcc command neglected]
> >> ...
> >> -ljvm -L/usr/lib/jvm/java-6-sun/jre/lib/amd64 -ljava
> >> -L/usr/lib/jvm/java-6-sun/jre/lib/amd64/server -ljvm -lc
> >> /usr/bin/ld: cannot find -ljvm
> >> because there is no amd64 under /usr/lib/jvm/java-6-sun/jre/lib but
> >> only i386, and without specifying ARCH the makefile relies on "uname
> >> -m" to guess the ARCH, and it chooses amd64 when seeing x86_64.
> >> So I tried to add ARCH=i386 in the command line. The build goes past
> >> the previous stage, but sees a different in building
> >> /bin/sh: line 5: Check_ALT_JDK_IMPORT_PATH/bin/javac: No such file or
> >> directory
> >> This problem is slightly off topic, as it seems to require adding
> >> ALT_JDK_IMPORT_PATH to the command-line even my intention is to do a
> >> complete build. Although I still don't know why it is necessary,
> >> adding ALT_JDK_IMPORT_PATH=$ALT_BOOTDIR gets me past corba, but the
> >> builds stalls at hotspot:
> >> make: *** No rule to make target
> >> `openjdk/v1_7/hotspot/src/cpu/i386/vm/x86_32.ad', needed by
> >> `../generated/adfiles/linux_x86_32.ad'. Stop.
> >> Apparenly hotspot doesn't like ARCH=i386 but prefers ARCH=x86, and I
> >> found a place to hack in hotspot/build/linux/Makefile, where I
> >> override ARCH=$(SRCARCH) in the following context:
> >> $(TARGETS_C2): $(SUBDIRS_C2)
> >> cd $(OSNAME)_$(BUILDARCH)_compiler2/$@ && $(MAKE) $(MFLAGS)
> >> ARCH=$(SRCARCH)
> >> Then, the next error shows up in exporting jvmti.html, where I need to
> >> add the following rule in hotspot/build/linux/makefiles
> >> /defs.make if I define ARCH as i386:
> >> ifeq ($(ARCH), i386)
> >> ARCH_DATA_MODEL = 32
> >> PLATFORM = linux-i586
> >> VM_PLATFORM = linux_i486
> >> HS_ARCH = x86
> >> endif
> >> There is a similar patch for i586 so I suspect people tried to build
> >> hotspot with ARCH=i686 and ran into similar errors.
> >> Well, this is not the end of errors, as the next one shows up in
> >> jdk/make/java/jli, where it fails to locate ergo_i386.c because only
> >> the following two variants are available:
> >> jdk/src/solaris/bin/ergo_i586.c
> >> jdk/src/solaris/bin/ergo_sparc.c
> >> In summary, my questions can be condensed into two:
> >> 1) Is control/make the right place to build everything from source. If
> >> so, why is ALT_JDK_IMPORT_PATH needed in the make command line?
> >> 2) What is the ARCH value applicable to all modules if the goal is to
> >> build 32-bit package on x86_64 platform?
> >> Thanks,
> >> -Ben
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the build-dev