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

[Jan Mikkelsen]

Hi,

I reported something similar on FreeBSD some time ago:

http://gcc.gnu.org/ml/java/2001-10/msg00090.html

Unfortunately, I never got around to sending the patch to
libtool-patches as was suggested.  Sorry about that :-(.

Regards,

Jan Mikkelsen


> -----Original Message-----
> From: java-owner@gcc.gnu.org [mailto:java-owner@gcc.gnu.org] 
> On Behalf Of Loren James Rittle
> Sent: Wednesday, 24 April 2002 5:16 PM
> To: java@gcc.gnu.org
> Subject: Report about -static failing when libgcj.a built with GNU ar
> 
> 
> 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
>