Report about -static failing when libgcj.a built with GNU ar

[Loren James Rittle <rittle at latour dot rsch dot comm dot mot dot com>]

A fellow gcc developer that bootstraps GCC with --disable-shared
reported a bootstrap failure on i386-*-freebsd* with that
configuration.  I didn't see it with the default --enable-shared port
configuration but I now understand the issue.

Doing a little research, it looks like FreeBSD (which uses GNU ar) has
the same issue found with Darwin (which was reported to use BSD ar)
back in January:

http://gcc.gnu.org/ml/java/2002-01/msg00005.html

Jeff Sturm posted the root cause here:

http://gcc.gnu.org/ml/java/2002-01/msg00037.html

By default, neither GNU ar 2.11.2 20010719 [FreeBSD] (as shipped with
OS sources) nor GNU ar 2.12.1 20020412 (prerelease from FSF tree as
taken today) appears to save/use path information (as required by
libgcj).

This issue should be hitting every port that uses GNU ar; when people
link with -static; or, at bootstrap time, when they configure with
--disable-shared.

; gcj --main\=hello -pthread -g hello.java
; gcj --main\=hello -pthread -static -g hello.java
[...82 lines of errors for missing references, same as Andreas posted...]

(That same error pops up during bootstrap, if configured without
shared libraries.)

This is not a regression on this platform since --enable-libgcj was
not the default for gcc 3.0 but it might be a regression on another
platform.

It appears the thread to fix this issue died out without any final
resolution (i.e. libjava or libtool patch).  It looks like adding the
P option whenever `ar' is GNU `ar' is required to fix this bug, at
least, until libgcj.a is built in one step.

AR_FLAGS is actually set at top-level Makefile.in not within libtool
configuration files or libjava/Makefile.in itself (that itself seems
like a bug; since libtool is suppose to be the master of building
libraries).

Statically changing the top-level Makefile.in default is not really
correct either since I see, e.g., Solaris ar doesn't support P (and
will fail if provided).  And the user may have installed GNU ar on any
port (especially for cross-compiler environments, I would think).
Yuck: It looks like the ``ar'' to be used by the bootstrap process
must be provided at configure time like ``ld'' and ``as''.  When it is
seen to be GNU ar, ``P'' must be added to AR_FLAGS (at least when
libtool is built within libjava).

[David, instead of my first workaround (e.g. --disable-libgcj when
 --disable-shared), since you control the bootstrap make in your
 process, you could use: ``gmake AR_FLAGS=rcP bootstrap'' (which builds
 a complete libgcj.a) instead of ``gmake bootstrap'']

Regards,
Loren