Cay Horstmann's Blog

Honey, I built the JDK! (on Ubuntu)

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.

1. In addition to the basic GCC tools, you need the following packages installed:
   • ksh
   • gawk
   • m4
   • libasound-dev
   • libcupsys2-dev
   • libx11-dev
2. Install the binary Mustang distribution, e.g. in /home/me/jdk1.6.0
3. You need a binary 1.5 distribution, e.g. in /home/me/jdk1.5.0
4. Make directories for the source and the output, e.g. /home/me/mustangsrc and /home/me/mustangout
5. 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

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

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

8. 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.
9. 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

10. 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
11. 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) ;
    */
    

12. 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.
13. 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
      

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

15. It walks, it talks!

    cd /home/me/mustangout
    bin/java -jar demo/jfc/SwingSet2/SwingSet2.jar

Comments

• 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

• Here is another article that describes the procedure for a later build: http://blogs.sun.com/navi/entry/try_this_at_home_building

  Posted by: cayhorstmann on August 26, 2006 at 05:56 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

This work is licensed under a Creative Commons License.