On Nov 28, 2007 10:47 AM, Kelly O'Hair <[EMAIL PROTECTED]> 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 >
