public inbox for java@gcc.gnu.org
 help / color / mirror / Atom feed
* Report about -static failing when libgcj.a built with GNU ar
@ 2002-04-24  6:20 Loren James Rittle
  2002-04-24  7:54 ` Jan Mikkelsen
  0 siblings, 1 reply; 3+ messages in thread
From: Loren James Rittle @ 2002-04-24  6:20 UTC (permalink / raw)
  To: java

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2002-04-24 14:54 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-04-24  6:20 Report about -static failing when libgcj.a built with GNU ar Loren James Rittle
2002-04-24  7:54 ` Jan Mikkelsen
2002-04-24  8:42   ` Loren James Rittle

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).