From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9188 invoked by alias); 24 Apr 2002 13:20:26 -0000 Mailing-List: contact java-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: java-owner@gcc.gnu.org Received: (qmail 9173 invoked from network); 24 Apr 2002 13:20:24 -0000 Received: from unknown (HELO dm.transactionware.com) (203.14.245.8) by sources.redhat.com with SMTP; 24 Apr 2002 13:20:24 -0000 Received: (qmail 26852 invoked from network); 24 Apr 2002 13:31:41 -0000 Received: from new.transactionware.com (192.168.1.55) by dm.transactionware.com with SMTP; 24 Apr 2002 13:31:41 -0000 Received: (qmail 59620 invoked by uid 1006); 24 Apr 2002 13:19:00 -0000 Received: from janm@transactionware.com by new.transactionware.com by uid 1003 with qmail-scanner-1.10 (uvscan: v4.1.40/v4195. . Clear:0. Processed in 0.462707 secs); 24 Apr 2002 13:19:00 -0000 Received: from mosm1.transactionware.com (HELO mosm1) (192.168.1.130) by new.transactionware.com with SMTP; 24 Apr 2002 13:18:59 -0000 From: "Jan Mikkelsen" To: , Subject: RE: Report about -static failing when libgcj.a built with GNU ar Date: Wed, 24 Apr 2002 07:54:00 -0000 Organization: Transactionware Message-ID: <000c01c1eb92$5ca033c0$8201a8c0@mosm1> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Importance: Normal In-Reply-To: <200204240715.g3O7FvI38158@latour.rsch.comm.mot.com> X-SW-Source: 2002-04/txt/msg00340.txt.bz2 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 >