Linux linker supports version script, which is the equivalent of Solaris
linker mapfile. Linux version scripts are designed to have the same
format as Solaris mapfiles, but with some limitations (e.g. no duplicate
version strings or symbols).

Currently linker mapfiles are enabled for the Solaris build to limit
exported dynamic symbols, but the mapfiles are not used in the Linux 
build. We should be able to directly use most of the Solaris mapfiles
on Linux and it should be quite easy to convert the rest.

The primary benefit of limiting dynamic symbols is to avoid potential
 customer  conflicts. And when this is used with statically linking libstdc++,
we should be able to support JNI libraries built by different version of
g++ without the annoying system abort due to conflicting libstdc++ 
functions. Limiting dynamic symbols should also generate slightly smaller
.so files and faster startup time.

N/A

needed for both HotSpot and JDK workspace

  xxxxx@xxxxx   2002-11-11

The linker mapfiles have been enabled on Linux/x86 in both the HotSpot and 
J2SE workspace. 

In HotSpot we use separate mapfiles because there are some Linux specific
symbols need to be exported. In J2SE, we just use the same mapfiles used
on Solaris except for libawt.so. Mapfile is currently disabled for libawt.so
because awt on Linux is statically linked with motif, enabling mapfiles
would hide all the Xm symbols.

After this change, internal symbols will be hidden from user code. User
code uses VM internal functions or variables directly could fail due to 
unresolved symbols. (Note the same code should already fail on Solaris 
and Windows, because the symbols are already hidden on Solaris and Windows) 
And the problem should be fixed in user code. 

Also please note the JVM interface is considered internal and unsupported 
even though the JVM_XXXX symbols are exported from libjvm.so. While we certainly
would like to maintain compatibility between different releases, the interface
could change or disappear at any time without notice.

Limiting dynamic symbols can reduce the possibility of symbol conflicts,
reduce library file size and slightly improve the performance.

  xxxxx@xxxxx   2002-11-15