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

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

[Loren James Rittle]

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

RE: 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
> 

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

[Loren James Rittle]

In article <000c01c1eb92$5ca033c0$8201a8c0@mosm1> you write:

> I reported something similar on FreeBSD some time ago:

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

Hi Jan,

Your patch was probably good if we just want to fix FreeBSD but please
note that (unless I'm confused) this issue affects -static on all
platforms that use recent releases of GNU ar not just FreeBSD.
Although I mainly use FreeBSD, I attempt to wear my gcc hat as much as
possible when putting patches into the FSF tree.

Another issue to consider: GNU ar 2.9.1 doesn't accept P.  Even
FreeBSD 4 (and Red Hat 6.1) shipped with GNU ar 2.9.1.  In any event,
no static configuration patch will really account for this issue
properly since users could have installed on any system a copy of GNU
ar that (a) allows P and (b) requires P to properly build libgcj.a.
We are suppose to adapt to what we actually find; never assume based
on OS type and version.

Regards,
Loren