[build,libjava] Support Sun symbol versioning in libjava

[Please keep me on the Cc:, I'm not subscribed to java-patches.  Thanks.]

After the precedent established by the patch to support Sun symbol
versioning in libstdc++

	PATCH: Support Sun symbol versioning in libstdc++-v3
        http://gcc.gnu.org/ml/gcc-patches/2010-02/msg01001.html

and its revision

	[build, doc, v3] Support Sun symbol versioning in libstdc++-v3, rev. 2
        http://gcc.gnu.org/ml/gcc-patches/2010-06/msg03182.html

libjava appeared relatively easy at first:

* One issue of note is that the original map file in configure.ac used
  wildcards, which Sun ld cannot handle as described, so I need to use a
  different mapfile here.

* Apart from that, I've reformatted the mapfile to make it easier to
  parse for the make_sunver.pl script.

While this worked initially, a bootstrap revealed an additional problem,
namely the use of the same mapfile for various different target
libraries.  Since for Sun ld corresponding mapfiles need to be generated
at build time and depend on the target library, I need to use different
*_version_arg variables to add to the *_la_LINK variables instead of the
common additon to extra_ldflags_libjava.  I also need per-library
variables to hold the mapfile as a dependency, which allows me to
somewhat simplify the Makefile.am, since I can set those variables even
in the unversioned case.

The main problem was that I cannot use the simple target used in the
other versioned libraries to generate the Sun mapfile, since I'd like to
avoid duplicating the same pattern over and over again.  It turned out
that the GNU make .SECONDEXPANSION: target comes in handy, since it
allows me to use automatic variables in the requisites of pattern rules.
I had to move both the .SECONDEXPANSION: target and the pattern rule to
the end of Makefile.am since otherwise filenames with $'s (which are
common inside libjava) are also expanded a second time, breaking the
build.

There's one other issue which caused me some headache: the pattern rule
I use to generate the sun version maps has a dependency on the object
files and libraries used to build the target library.  As I said,
.SECONDEXPANSION: allows me to refer to the make target with $$@ and
indirectly reference the *_la_OBJECTS and *_la_LIBADD variables.
Unfortunately, this breaks for libgcj_tools_la_LIBADD, which contains
-lm, which of course doesn't exist as a filename, breaking the build.
My solution was to move -lm (which is needed for an instance of fmod in
libgcj-tools.so) to libgcj_tools_la_LDFLAGS instead.  The Automake
manual suggests this is allowed.

Another complication that I hadn't come across with the other target
libraries was the creation of libgcj-tools.so.  It depends, via
libgcj_tools_la_LIBADD, on libgcj.la.  Before, the rules to generate the
Sun version map would look at every .o and .a file corresponding to the
.lo and .la files and add every symbol found in one of them to the
generated map.  In the case of libgcj.la, this is wrong: while libgcj.a
exists and provides tons of symbols, the actual link is against the
shared version, libgcj.so.  My solution was to just skip archive
libraries passed info the make_sunver.pl script in case a corresponding
.so file existed as well.

Again, the output of pvs -dsvo after bootstraps with Sun ld and GNU ld
on i386-pc-solaris2.11 were almost identical, with the expected

[build,libjava] Support Sun symbol versioning in libjava

Commit Message

Comments

Patch