Skip to main content

Where can i get jdk compiled with debug information?

3 replies [Last post]
Joined: 2003-06-30

I need jdk1.6.0 compiled with debug information for linux x86, to see output produced by J2dTraceLn

Or may be someone have only /jre/lib/i386/xawt/ with debug output?

Details why i need it here...

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Joined: 2004-09-03

We are working on providing the 'fastdebug' built bits on the download site, but it may take a few weeks for these to show up. The fastdebug builds are '-g -O'.

Joined: 2004-09-03

Also see:

We have 3 basic types of builds with Mustang: product, fastdebug, and debug. We regularly (nightly and all snapshots) build the product and fastdebug builds of the JDK. The debug builds are currently only done by the developers, and only if they need them.

We use the term fastdebug because we want a debug version but we also want the Java VM to run fast enough to test and use in regular situations. So the fastdebug build will have all the debug information in the jar files (we use javac -g) and all the native code will have been built with '-g -O' (optimized native code, but with -g). In addition, any runtime debugging code (-DDEBUG type native code) is also included in the fastdebug version, which means, for example, that the VM has additional assert checking enabled to verify that the VM is behaving as expected as your java application runs.

Whew... ok what does this have to do with answering the question? First, we are trying to make the fastdebug build available as a download. Second, this may or may not help your exact situation. If you were after the 'javac -g' debug information so you could run a java debugger on the runtime classes, you should be happy with the fastdebug builds. But if you wanted full debugging capabilities of the native code, you may not have enough to do this and may need to build the JDK yourself.

Native debuggers all work differently, but at a minimum most need access to the shared libraries with the debug information intact (true with the fastdebug builds), and access to the exact source files used to build the libraries. So if you have the matched set of sources and a fastdebug build, and you manage to tell the native debugger where those sources are, you should be ok for fastdebug debugging, retraces should work fine, basic debugging should work fine.

The exceptions I can think of at the moment are:

* On Solaris, sometimes some of the debug information is left in the object or .o files, and those files are not being provided in the fastdebug build images.

* On all platforms, this fastdebug native code has been optimized, and the debugger may not be able to provide you all debugging capabilities.

So often it's necessary to build your own fastdebug JDK on Solaris to get maximum debugging abilities. And sometimes it's necessary to build your own debug version if you want all the native debugger capabilities. It will depend on what you are after.

The good news is that the Mustang shared libraries are pretty much mix&match now, you can displace just one 'product' built library with a 'fastdebug' version or even a 'debug' version on Solaris or Linux, which is often all that is needed when you have zeroed in on one shared library. So we have tried to allow for developers to do something like this:

gnumake all # Build a product version
cd make/jpda/back
gnumake clean # Clean out product version of
gnumake fastdebug # Build a fastdebug version of

Then debugging this 'java' uses a fastdebug version of but an official product version of everything else.

Hope this helps in some way.

Joined: 2003-06-10

We recently also had this discussion on Javalobby. There is a solution for the 95+% debugging scenarios:

I hope this helps,