 |
Honey, I built the JDK! (on Ubuntu)
Posted by cayhorstmann on June 13, 2006 at 02:09 PM | Comments (10)
As any mad scientist would do, just
to prove that it can be done, I decided to build Mustang on my shiny new
Ubuntu 6.06 "Dapper Drake" system. The build
instructions warn you not to try this at home. The official build
environment is Redhat Enterprise Advanced Server 2.1 update 2, formerly
known as Redhat Advanced Server 2.1 update 2. Ugh.
I was not sure that this was going to work. Ubuntu is Debian based, and
it uses GCC 4.0, not GCC 3.2. As it turns out, the X11 headers have
recently moved to around, so I had some grief. But it all turned out well,
and I lived to tell the tale.
Why would anyone care? If you use Linux as your primary work OS (as I
do), and you switched to the increasingly popular Ubuntu, and you want to
tinker with the JDK, these instructions will save you time and
frustration. (Not that much time, maybe. It took me less than a day to
hack my way through.) For everyone else, it may be comforting to know that
someone with very limited system programming experience can do the build
in an unfamiliar environment. It certainly is a tribute to the Mustang
team who put this very complex build together.
Here are the instructions.
- In addition to the basic GCC tools, you need the following packages
installed:
- ksh
- gawk
- m4
- libasound-dev
- libcupsys2-dev
- libx11-dev
- Install the binary Mustang distribution, e.g. in
/home/me/jdk1.6.0
- You need a binary 1.5 distribution, e.g. in /home/me/jdk1.5.0
- Make directories for the source and the output, e.g.
/home/me/mustangsrc and /home/me/mustangout
- Download and install the JARs
cd mustangsrc
java -jar ../downloads/jdk-6-rc-src-b87-jrl-09_jun_2006.jar
java -jar ../downloads/jdk-6-rc-bin-b87-jrl-09_jun_2006.jar
java -jar ../downloads/jdk-6-rc-mozilla_headers-b87-unix-09_jun_2006.jar
- Set environment variables
unset JAVA_HOME
export ALT_BOOTDIR=/home/me/jdk1.5.0
export ALT_DEVTOOLS_PATH=/usr/bin
export ALT_GCC29_PLUGIN_LIB_PATH=/home/me/jdk1.6.0/jre/plugin/i386/ns7-gcc29
export ALT_MOZILLA_HEADERS_PATH=/home/me/mustangsrc/share/plugin/
export ALT_OUTPUTDIR=/home/me/mustangout
export MILESTONE=rc
export BUILD_NUMBER=b87
- In Ubuntu, basename is in /usr/bin, not in
/bin. In j2se/make/common/shared/Defs-utils.gmk, change the
definition of BASENAME to
BASENAME = $(UTILS_USR_BIN_PATH)basename
- To avoid the error execvp: cp: Too many levels of symbolic
links, make these changes:
- In hotspot/make/Makefile, change the definition of CP
from cp to /bin/cp:
CP=/bin/cp
- The file j2se/make/docs/Makefile has two cp that should
be $(CP), in the tagletapidocs: target.
- GCC 4.0 is pickier than GCC 3.2. Therefore, we won't fail on
warnings. Comment this out in j2se/make/docs/Makefile:
# WARNINGS_ARE_ERRORS = -Werror
- GCC 4.0 complains when redefining an extern function as
static. Comment out the word static in these function
definitions:
- j2se/src/solaris/hpi/native_threads/src/interrupt_md.c:113:
error: static declaration of ‘sigignore’ follows
non-static declaration
- j2se/src/share/native/sun/awt/cmm/spsearch.c:1335: error: static
declaration of ‘TestFileCB’ follows non-static
declaration
- j2se/src/share/back/error_messages.c:42: error: static
declaration of ‘vprint_message’ follows non-static
declaration
- j2se/src/javaws/share/native/launchFile.c:66: error: static
declaration of ‘iksSecureProperty’ follows non-static
declaration
- j2se/src/javaws/share/native/xmlparser.c:53: error: static
declaration of ‘RemoveNonAsciiUTF8FromBuffer’ follows
non-static declaration
- j2se/src/solaris/native/sun/awt/awt_dnd.c:172: error: static
declaration of ‘xerror_code’ follows non-static
declaration
- In j2se/src/solaris/native/sun/awt/awt_motif21.c, comment out this
declaration:
/*
extern XIC XmImGetXIC(
Widget w,
uint32_t input_policy,
ArgList args,
Cardinal num_args) ;
*/
- I fixed the error PIC register ‘%ebx’ clobbered in
‘asm’ in j2se/src/solaris/bin/java_md.c by commenting
out %ebx in the clobber declaration
"%eax", /* "%ebx", */ "%ecx", "%edx" I'd
like some expert to tell me if that is ok.
- Ubuntu 6.06 has a different location for several X11 files. Make
these changes:
- In motif/lib/Xm/util/Makefile, change IRULESRC to
IRULESRC=/etc/X11/config/cf
- In j2se/make/sun/xawt/Makefile, change
/usr/X11R6/include/X11/extensions to
/usr/include/X11/extensions:
ifeq ($(PLATFORM), linux)
CPPFLAGS += -I/usr/include/X11/extensions -I$(MOTIF_DIR)/include -I$(OPENWIN_HOME)/include
endif
and in j2se/make/sun/awt/mawt.gmk, change /usr/X11R6/lib to /usr/lib
(3x):LIBXT = /usr/lib/libXt.a
LIBSM = /usr/lib/libSM.a
LIBICE = /usr/lib/libICE.a
The build instructions
told me to run make scsl, but then I got an error complaining
about a missing jscheme/REPL. Following this
advice, I picked up with make j2se, and voila, it
worked.
It walks, it talks! cd /home/me/mustangout
bin/java -jar demo/jfc/SwingSet2/SwingSet2.jar
Bookmark blog post: del.icio.us Digg DZone Furl Reddit
Comments
Comments are listed in date ascending order (oldest first) | Post Comment
-
OK, maybe for the lesser mortals you can explain what it is you're actually doing here. I mean I see that you install the binary Mustang distribution. Which I think I follow. But what are all those jar files needed for?
What is the end goal you are trying to achieve?
Thanks!
Posted by: biffta on June 17, 2006 at 03:54 AM
-
biffta: I compiled Mustang from the source distribution. (The binary distribution is only needed for one oddball piece--a Netscape plugin compiled with an ancient compiler.) You would want to do that if you wanted to make some change to javac, or java, or one of the other tools, or one of the libraries.
I care because I have several improvements that I'd like to see in future versions of Java. If I submit a patch to the source, I have a much better chance than by filing a feature request.
Posted by: cayhorstmann on June 17, 2006 at 09:57 PM
-
I built mustang on FC4 three monts ago using a very similar procedure to Cay's instructions, I am trying now with FC5 and gcc 4.1. At this point I need to use the new -ffriend-injection option to gcc 4.1 but I dont know where to insert this option in the Makefiles :(
Posted by: alpatino on June 30, 2006 at 09:55 PM
-
Last update to build mustang b90 from source on FC5 with gcc 4.1:
after change vm.make file inside "hotspot/build/linux/makefiles/" with CFLAGS += -ffriend-injection and remove all the "extra qualification" redundant prefixes from:
b90/build/hotsp259ot/src/share/vm/memory/referenceProcessor.hpp
b90/build/hotspot/src/share/vm/runtime/thread.hpp:1593:
b90/build/hotspot/src/share/vm/runtime/classLoader.hpp:272:
b90/build/hotspot/src/share/vm/runtime/java.hpp:72:
b90/build/hotspot/src/share/vm/memory/symbolTable.hpp:162:
b90/build/hotspot/src/share/vm/runtime/signature.hpp:374:
b90/build/hotspot/src/share/vm/ci/ciObject.hpp:50:
b90/build/hotspot/src/share/vm/ci/ciObjectFactory.hpp:88:
b90/build/hotspot/src/share/vm/opto/callnode.hpp:321:
b90/build/hotspot/src/share/vm/opto/matcher.hpp:257:259:262:264
b90/dist/hotspot/outputdir/linux_i486_compiler2/generated/adfiles/ad_i486.cpp
b90/build/hotspot/src/cpu/i486/vm/interpreter_i486.hpp:79:
b90/build/hotspot/src/share/vm/opto/graphKit.hpp:521:
b90/build/hotspot/src/share/vm/opto/parse.hpp:411:
b90/build/hotspot/src/share/vm/runtime/compilationPolicy.hpp:61:
b90/build/hotspot/src/share/vm/runtime/compilationPolicy.hpp:62:
b90/build/hotspot/src/share/vm/prims/jvmtiEnvBase.hpp:256:
b90/build/hotspot/src/share/vm/gc_implementation/parallelScavenge/generationSizer.hpp:20
b90/build/hotspot/src/cpu/i486/vm/stubGenerator_i486.cpp:1293:
I got a gcc debug error generated with the vmStructs.cpp file:
b90/build/hotspot/src/share/vm/runtime/vmStructs.cpp:2289: internal compiler error: no-op convert from 4 to 8 bytes in initializer
This is a bug in gcc 4.1 pinpointed out in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27724
So we hope there will be a fix on gcc 4.2 release :(
Posted by: alpatino on July 04, 2006 at 10:10 PM
-
Anyone still reading this entry?
I'm curious if anyone has gotten Mustang b94 to build on Ubuntu. I followed these instructions; and also performed these hacks:
-
I added an export for: ALT_HOTSPOT_IMPORT_PATH=/home/me/jdk1.6.0
And then, during either a 'make scsl' or 'make j2se':
-
Make complained about fonts. I simply copied all the fonts from jdk1.6.0/jre/lib/fonts into the directory make complains about.
-
Make complained about handling gif and soundbank files in copies. I simply commented out the windows gif files and the soundbank file in the FILES.gmk and MAKEFILE in question.
But the make awt all fails with syntax errors:
[...]
Begin parallel compiles: /home/me/mustangsrc/j2se/make/sun/awtmake[4]: Entering directory `/home/me/mustangsrc/j2se/make/sun/awt'
[...]
../../../src/solaris/native/sun/awt/awt.h:144: error: syntax error before '*' token
[...]
../../../src/solaris/native/sun/awt/awt.h:145: error: syntax error before 'awt_appContext'
[...]
[others]
Anyone have any ideas?
I'll try a simpler bootstrapped javac compile to work on bug fixes in the awt and swing packages (in the java classes files)...
Posted by: steevcoco on August 04, 2006 at 10:13 PM
-
As far as problems with fonts missing, gif files missing.... There is a "Binaries for Source" bundle that must be separately downloaded and overlayed on the Source bundle result directory. This "Binaries for Source" file contains the font files and gifs that require a special license acceptance, the name of this bundle is confusing, it's a set of files that happened to have been labeled 'binaries' and need to be added to the source tree. So to create a buildable JDK source tree (before you ever do a 'make dev') you need to download the Source jar file and the 'Binaries for Source' file, and make sure all these files get overlayed.
Hope this helps.
-kto
Posted by: kellyohair on August 15, 2006 at 02:11 PM
-
Notice that the Ubuntu package you need to install ksh is actually called "pdksh".
Posted by: sunnychangs on September 27, 2006 at 03:17 AM
-
I have tried to build the JDK on Fedora Core 6 Test 3, using similar modification, etc. However the linked binary doesn't work - when it runs, the dynamic loader compaints:
./gamma: error while loading shared libraries: ./libjvm.so: unexpected PLT reloc type 0x08
This is very "helpful" as it doesn't tell me which symbols it has problem with :-( Anyone seem this before?
Posted by: sunnychangs on September 27, 2006 at 03:36 AM
-
I fixed the error PIC register ‘%ebx’ clobbered in ‘asm’ in j2se/src/solaris/bin/java_md.c by commenting out %ebx in the clobber declaration
"%eax", /* "%ebx", */ "%ecx", "%edx"
I'd like some expert to tell me if that is ok.
I looked at the source from 22nd June (jdk-6u2-fcs-src-b05-jrl-22_jun_2007.jar) and removing the ebx clobber declaration is ok in both hotspot/src/os/linux/launcher/java_md.c
and hotspot/src/os/solaris/launcher/java_md.c. Both of these save and restore ebx in the cpuid instruction, so they don't actually clobber ebx and I'm guessing that it's just an oversight that it hasn't been removed there.
In j2se/src/solaris/bin/java_md.c, the unnecessary clobber has already been removed - ebx is saved and restored so that's ok too.
I don't know what version you built, so can't say whether what you did was ok or not - if the assembly section has 'pushl %%ebx' at the beginning and 'popl %%ebx' at the end, then you were ok.
Normally, commenting out clobbers will get stuff to compile (assemble) but will result in incorrect code. Essentially when the clobber list is wrong, you're lying to the compiler about what registers are modified by the assembly code. The compiler assumes anything not in the clobber list is unmodified, so if a register is modified but not in the clobber list, subsequent code that relied on the value prior to the assembly section will fail.
EBX is used in shared libraries to create position-independent code, and it is used by gcc in a way that requires its value to be retained for the duration of a function (for reasons of efficiency). In normal code (i.e. the main app rather than shared libraries) it has no special meaning, and gcc allows it to be clobbered.
Posted by: kevquinn on September 16, 2007 at 03:40 AM
|