Thanks Phil!
I just found similar explanation in the jdk\make\common\Makefile-vers.gmk
#
# Makefile for linking with mapfiles.
#
# NOTE: Not using a mapfile will expose all your extern functions and
# extern data symbols as part of your interface, so unless your
# extern names are safe from being mistaken as names from other
# libraries, you better use a mapfile, or use a unique naming
# convention on all your extern symbols.
#
# The mapfile will establish versioning by defining the exported interface.
#
# The mapfile can also force certain .o files or elf sections into the
# the different segments of the resulting library/program image.
#
# The macro FILES_m can contain any number of mapfiles.
#
However, it seems to be used on Linux/Solaris only (everything inside is
under ifder solaris/linux) and this puzzle me a bit.
So, it seems if name clashing is primary reason we should be protecting
from this on Windows too.
-igor
Phil Race wrote:
Igor Nekrestyanov wrote:
Thank you many many times for this, I don't know how long further I
would have searched without this information.
What is this file good for and how is it used during the build?
I believe mapfiles are used to defines set of methods to be exported
from shared library.
Perhaps, you may grep build log file for mapfile name to see how this
is done exactly
(do not have linux build here and have not checked log myself).
My understanding of why we use this is following.
Symbol tables for all methods from the library are large and explicit
control on set of exported methods
is workaround to reduce library file size (and size has impact on
memory footprint, download footprint, startup time, etc.).
I don't know how much it helps any of these but the principal reason
has always been to avoid
potential name space clashes. For the most part the only symbols that
need to be exported are
the names of JNI methods. ie the entry points from Java code into native.
-phil.
