how to build 32-bit openjdk7 on x86_64

[Kelly O'Hair]

 From earlier emails... it appears you are trying to build 32bit on a 64bit machine?

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. ;^)

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