i386-*-freebsd* --enable-libgcj bootstrap broken within last week

[Loren James Rittle]

It appears that two independent libjava patches have recently broken
the i386-*-freebsd* --enable-libgcj bootstrap.  The first problem is
exposed either because all i386 targets now use slow_pthread_self=yes
(isn't this a per-OS or per-OS-on-CPU issue not a per-CPU issue?) thus
we see a different code path than we used to see and/or that code path
was updated on the same day to use locks.h code.  An additional cast
is required to safely use a pthread_t across the release_set API since
it may be a pointer under some implementations.  I will post this
under separate cover to java-patches.

The proper solution to the other situation completely eludes me.  This
recent patch (which is probably quite right in principle):

	* Makefile.am (jv_convert_LDADD): Don't list libraries that are
	already implicitly brought in from libgcj.la.
	(gij_LDADD, rmic_LDADD, rmiregistry_LDADD): Likewise.
	* Makefile.in: Rebuilt.

	[See http://gcc.gnu.org/ml/java-patches/2002-q1/msg00774.html]

appears to have broken the (probably kludgy) mechanism we used to
build Java executables on FreeBSD 4 under our default multithreaded
configuration.  Unrolling -j1.222 -j1.221 Makefile.in, allowed a
bootstrap to complete.

In libjava/Makefile, we have: ``THREADLIBS = -pthread'', thus until
the above patch, all executables linked from libjava/Makefile got the
command line option we need to build multithreaded executables (really
any executable that references pthread_* symbols in a non-weak
fashion).  With the above patch, we lose it.  This artificial library
specification flag is not ``implicitly brought in from libgcj.la''.
It would actually solve many remaining issues with libgcj on FreeBSD 4
if it actually did so.  Reading libtool sections of "Autoconf,
automake, and libtool" revealed nothing about this issue to me.

Do I need to teach libtool that -pthread is a proper, if artificial,
library specification flag on FreeBSD 4?  I see no hook in the
existing script that would support such flags.  This looks like a
daunting task for a non-libtool maintainer.

If not, what is the correct way to arrange to properly stuff that flag
into the built libgcj.la and have it get processed properly when
someone builds against the .la?  Looking over the libtool script, it
appears that it will not currently pass/add such artificial library
specification flags.

Regards,
Loren