Skip to main content

Are you Building the J2SE?

19 replies [Last post]
kellyohair
Offline
Joined: 2004-09-03
Points: 0

The J2SE build instructions are posted here:
http://www.java.net/download/build.html

We know this is not an easy machine setup procedure and we are currently working on making this easier. Windows is unfortunately the hardest machine to setup, so our efforts are focusing on Windows setup/build issues. Expect separate posts on these efforts.

We'd like to know who has actually tried (successfully or not) to setup or build the J2SE, and we like to hear from you what went well or not so well.

Let us know.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vijayj
Offline
Joined: 2004-10-26
Points: 0

Looks like you manage to build hotspot workspace?. The problem you are facing right now is from the j2se workspace. You could possibly be running onto the bug id 4656697.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4656697

This bug will never be fixed, but we have disabled the use of javah_g as part of our build in the 5.0 update release and 6.0 mustang release.

Simple work around would be change the line no 506 in the j2se/make/common/Defs.gmk

From

JAVAH_CMD = $(BINDIR)/javah$(SUFFIX)

To

JAVAH_CMD = $(BINDIR)/javah$(OPT_SUFFIX)

Thanks,
Vijayan.

dushyanthb
Offline
Joined: 2005-03-12
Points: 0

hey

I tried exactly what you did. BUt am getting the same bunch of errors.

/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:465:1: pasting "::" and "start" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:466:1: pasting "::" and "end" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:467:1: pasting "::" and "top" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:468:1: pasting "::" and "size" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:469:1: pasting "::" and "refill_waste_limit" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:470:1: pasting "::" and "number_of_refills" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:471:1: pasting "::" and "fast_refill_waste" does not give a valid preprocessing token
/export/home/dushyanth/java_src/src/hotspot/src/share/vm/runtime/thread.hpp:472:1: pasting "::" and "slow_allocations" does not give a valid preprocessing token

I would be very glad if you can help me out with this.. Am using gcc version 3.2, running in FC 2 and also i put the gcc 3.2 bin in PATH Variable... Also kindly let me know in which file should i change the BUILD_INSTALL and DEPLOY? please let me know. I will be very greatful.

sincerely,

dushyanth

kellyohair
Offline
Joined: 2004-09-03
Points: 0

In these Tiger JDK 5.0 sources, edit the file hotspot/src/share/vm/runtime/thread.hpp, changing this:

#define TLAB_FIELD_OFFSET(name) \
static ByteSize tlab_##name##_offset() { return byte_offset_of(Thre
ad, _tlab) + ThreadLocalAllocBuffer::##name##_offset(); }

To this:

#define TLAB_FIELD_OFFSET(name) \
static ByteSize tlab_##name##_offset() { return byte_offset_of(Thre
ad, _tlab) + ThreadLocalAllocBuffer::name##_offset(); }

Effectively getting rid of the extra ## before the argument 'name'.

See if that helps.

But you must realize that you are building Tiger (JDK 5) with a compiler that it was never built with before, and you could (probably will) run into much worse problems than this.

-kto

vijayj
Offline
Joined: 2004-10-26
Points: 0

> First I would like to know where to get hold of the previous java release jre bundles and the previous java release sdk bundles needed in the installation process.

You must be using “all” target from the control workspace?. You can set SKIP_COMPARE_IMAGES to true to escape this part. You don’t need the previous release bundles.

Thanks,
Vijayan.

jdnx
Offline
Joined: 2005-02-15
Points: 0

It seems like I managed to build the JDK 1.5.0 with the following:
make DEPLOY= BUILD_INSTALL=false SKIP_COMPARE_IMAGES=true

Tried running the vm and compiler, they worked fine, hope the rest is working ;->.

Thanks a lot to kellyohair and vijayj for their very helpful comments.

vijayj
Offline
Joined: 2004-10-26
Points: 0

Hi,

Did you download and install the "JDK Binaries for Source Build 6.0"?.

http://www.java.net/download/jdk-6_0-ea-bin-b23-jrl-10_feb_2005.jar

You need to download this file and install on top of the "JDK 6.0 Source under the JRL license" bundle installation.

--
Thanks,
Vijayan.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

It appears that the j2se/make/redist/Makefile just does an install of these files from the j2se/src/share/lib/fonts directory. The make rule is pretty simple so I don't see what could go wrong here. The log might be helpful, also what version of gnumake is being used, gnumake --v.

Make sure the ttf files exist at j2se/src/share/lib/fonts.

sr29067
Offline
Joined: 2004-05-07
Points: 0

I worked through the Makefiles and found the rule for building the font files. It just does a copy from j2se/src/share/lib/fonts, as you say. The problem is that, because I've disabled the build of the plugin (which includes webstart), the font files are not being copied from the JRE to the j2se fonts directory in the build tree. Because the source files are not there and they are part of the dependency for the rule make reports no rule found.

Although I could just build the plugin, I'll probably modify the makefile to reduce the interdependancy between the plugin and the rest of the build.

Thanks a lot for your help (especially since I'm not using the build environment specified in the build instructions, or doing it quite the right way).

Simon.

jdnx
Offline
Joined: 2005-02-15
Points: 0

I have tried to build the JDK 5.0 source via JRL downloaded from http://java.sun.com/j2se/1.5.0/download.jsp
and I am trying to build it on a Fedora core 2 system. I know that this forum is for Mustang, but I hope this is
sufficiently relevant...

I've read the build instructions and understand that this is not the supported platform.

First I would like to know where to get hold of the previous java release jre bundles and
the previous java release sdk bundles needed in the installation process.

Second I have managed to get by the checks, but when running the make script in control/make I get the following error message:

Compiling /jdnx/Programs/jdk/hotspot/src/share/vm/utilities/accessFlags.cpp
In file included from ../generated/incls/_accessFlags.cpp.incl:132,
from /jdnx/Programs/jdk/hotspot/src/share/vm/utilities/accessFlags.cpp:10:
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:465:26: pasting "::" and "start" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:466:24: pasting "::" and "end" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:467:24: pasting "::" and "top" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:468:25: pasting "::" and "size" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:469:39: pasting "::" and "refill_waste_limit" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:470:38: pasting "::" and "number_of_refills" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:471:38: pasting "::" and "fast_refill_waste" does not give a valid preprocessing token
/jdnx/Programs/jdk/hotspot/src/share/vm/runtime/thread.hpp:472:37: pasting "::" and "slow_allocations" does not give a valid preprocessing token
make[3]: *** [accessFlags.o] Error 1
make[3]: Leaving directory `/jdnx/Programs/jdk/control/build/linux-i586/hotspot-i586/tmp/linux_i486_compiler2/product'

It looks like the macro expanded code is not legal code!?!

Any suggestions or ideas are very much appreciated?

kellyohair
Offline
Joined: 2004-09-03
Points: 0

The macro in question seems to be TLAB_FIELD_OFFSET:

#define TLAB_FIELD_OFFSET(name) \
static ByteSize tlab_##name##_offset() { return byte_offset_of(Thread, _tlab) + ThreadLocalAllocBuffer::name##_offset(); }

Which seems pretty straight-forward to me, but I know C preprocessing pretty well.
I'd suspect that something is wrong with the preprocessor in use. There is no requested concatenation of :: with name.

Which compiler are you using?

jdnx
Offline
Joined: 2005-02-15
Points: 0

gnu gcc version 3.2.2.

I have compiled gcc version 3.2.2, and pointed to the location of the gcc executable using the ALT_COMPILER_PATH env. var.

I tried to compile the macro separately using the newly build gcc 3.2.2, and it worked ok! So I guess the version accessed by the make script is not the one I build...

I have looked in the sanitycheckmessage and it reports the correct version and path of gcc 3.2.2.

Is there any way of verifying the version used in the make script?

kellyohair
Offline
Joined: 2004-09-03
Points: 0

I'd make sure that the gcc you want to use is in your PATH too. The hotspot Makefiles by default use the PATH, and not the ALT_COMPILER_PATH setting. This was a compilation of a hotspot source file.

So do both, make sure gcc is in your PATH, and set ALT_COMPILER_PATH.

---
The hotspot workspace is somewhat disconnected from the other workspaces, it's makefiles are a different breed of animal. Most of the hotspot engineers just build hotspot, and then plop that build hotspot into a already built JDK.
Most of the non-hotspot engineers don't build hotspot, and just copy in the hotspot from a previous build.
Just fyi.

jdnx
Offline
Joined: 2005-02-15
Points: 0

>So do both, make sure gcc is in your PATH, and set >ALT_COMPILER_PATH.

That worked, putting gcc in the PATH! Thanks!

The vm's, the compiler and some other tools are built and are working.

The building process halts some where further along with the following segmentation fault I can't figure out what it is trying to build?

/jdnx/Programs/jdk/control/build/linux-i586/bin/javah_g -J-XX:ThreadStackSize=768 -jni -bootclasspath /jdnx/Programs/jdk/control/build/linux-i586/classes -d /jdnx/Programs/jdk/control/build/linux-i586/tmp/java/java.lang.management/management/CClassHeaders/ \
sun.management.ClassLoadingImpl sun.management.FileSystemImpl sun.management.GarbageCollectorImpl sun.management.GcInfoBuilder sun.management.HotspotRuntime sun.management.HotspotThread sun.management.MemoryImpl sun.management.MemoryManagerImpl sun.management.MemoryPoolImpl sun.management.ThreadImpl sun.management.VMManagementImpl com.sun.management.UnixOperatingSystem
VM option 'ThreadStackSize=768'
make[4]: *** [/jdnx/Programs/jdk/control/build/linux-i586/tmp/java/java.lang.management/management/obj_g/.class.headers.i586] Segmentation fault
make[4]: Leaving directory `/jdnx/Programs/jdk/j2se/make/java/management'

kellyohair
Offline
Joined: 2004-09-03
Points: 0

This sounds like bug 4656697 which was a problem with glibc on Linux, sounds like it was fixed in glibc-2.2.5. Use of javah_g would trigger the crash. But in the j2se Makefiles, there is a macro JAVAH_SUFFIX which should be set to empty and should have made all uses of javah to never actually use the javah_g version. Your post shows the use of javah_g, so I'm a bit puzzled why it's using javah_g.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

Ah... You said this was 5.0 sources right? Maybe the javah_g->javah change wasn't made in the 5.0 sources.

Try going to j2se/make/common/Defs-linux.gmk and make sure the SUFFIX on JAVAH is the OPT_SUFFIX and not the DBG_SUFFIX. That might fix this.

sr29067
Offline
Joined: 2004-05-07
Points: 0

I just started trying to build Mustang. I'm trying to build it on SuSE Linux 9.1, which I realise is not the supported platform for a Linux build. My idea is to document what it takes to build on a different platform to help other developers.

I've read the build instructions. The problem I'm working with at the moment is how to tell the build not to attempt to build the plugin so that I don't need the older version of GCC, plus convincing it that the platform I have does meet the needs of the build.

kellyohair
Offline
Joined: 2004-09-03
Points: 0

Try setting DEPLOY= (empty) and you probably want to
do a BUILD_INSTALL=false. e.g.

cd control/make; gnumake DEPLOY= BUILD_INSTALL=false

The deploy area is the one that has the plugin.

Or you might be able to just 'mv deploy deploy-', but I haven't tried that.

sr29067
Offline
Joined: 2004-05-07
Points: 0

Thanks for the feedback. I got round the problem by modifying the BUILD_PLUGIN variable in the make/common/Defs.gmk file to false. Using DEPLOY= is obviously better.

The build goes quite a long way, but fails in mustang/j2se/make/java/redist, saying that there is no rule to make target mustang/control/build/linux-i586/lib/fonts/LucidaTypewriterRegular.ttf

I had a dig through the Makefile and it seems the FILES.gmk file in included that lists a number of Truetype font files. This list is appended to the optimised build list. I've looked at the files that get included into this makefile, but can't see anything obvious that would identify where the build rule for these fonts is; it's not in the Makefile in redist.

I'll keep digging.

bino_george
Offline
Joined: 2003-06-16
Points: 0

Hi,

> The build goes quite a long way, but fails in
> mustang/j2se/make/java/redist, saying that there is
> no rule to make target
> mustang/control/build/linux-i586/lib/fonts/LucidaTypew
> riterRegular.ttf
>

Can you send me a log of the debug output
(maybe in a compressed form). Make sure you do a
gnumake clobber before you do this, so that it is a
a fresh build. I cant seem to reproduce this problem.

Thanks,
Bino.