how to build 32-bit openjdk7 on x86_64

[Ben Cheng]

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
> machines.
> 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.

Thanks,
-Ben


> 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).
>
> -kto
>
> 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
> ARCH,
> > 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
> like
> > 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
> me)
> >
> > ---
> > 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
> corba/make/javax/xa:
> >>
> >> /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[6]: *** 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...
URL: <https://mail.openjdk.org/pipermail/build-dev/attachments/20071128/ebff5eaf/attachment.htm>