The 1.5 jvm (build 1.5.0-beta-b32) uses the zlib compression library for
processing manifests. The symbols within the jvms private version of 
libz have a global scope and are therefore available as interfaces for
other modules within the jvms address space (i.e JNI code) to bind to
at link time.

This causes a problem for JNI libraries that have a dependency on libz.
In our case, any DTrace consumer library will link in libctf.so.1 which
in turn has a dependency on libz.so.1. Ordinarily this will be resolved
against the libz.so.1 provided with Solaris in /usr/lib but, in this
case, any binding is done against the versions that are private to the
jvm.

At the moment this breaks 64 bit JNI applications as the private libz
that the jvm uses is compiled differently (uLong == 4 bytes instead of 8
on LP64 data model) to the libz.so.1 that is shipped with Solaris. All
DTrace consumers have to be 64 bit.

The scope of the jvms internal compression routines should be modified
so that they are not available to link against when modules are loaded
into the jvm.

N/A

  xxxxx@xxxxx   2004-07-26
This problem was introduced in Solaris by the multiple JRE work.
As part of this the launcher itself has a private set of a few
zip routines (This in itself is an exoediancy to be removed).
These symbols are the ones clashing with Dtrace on Solaris.

The fix is to use a ld mapfile to scope these symbols (and most others
while we are at it) to be local to the launcher.