Return-Path: Delivered-To: apmail-incubator-stdcxx-dev-archive@www.apache.org Received: (qmail 80284 invoked from network); 6 Jul 2006 17:59:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 6 Jul 2006 17:59:07 -0000 Received: (qmail 48082 invoked by uid 500); 6 Jul 2006 17:59:06 -0000 Delivered-To: apmail-incubator-stdcxx-dev-archive@incubator.apache.org Received: (qmail 48063 invoked by uid 500); 6 Jul 2006 17:59:06 -0000 Mailing-List: contact stdcxx-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: stdcxx-dev@incubator.apache.org Delivered-To: mailing list stdcxx-dev@incubator.apache.org Received: (qmail 48050 invoked by uid 99); 6 Jul 2006 17:59:06 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 10:59:06 -0700 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: neutral (asf.osuosl.org: local policy) Received: from [208.30.140.160] (HELO moroha.quovadx.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 06 Jul 2006 10:59:03 -0700 Received: from qxvcexch01.ad.quovadx.com (qxvcexch01.ad.quovadx.com [192.168.170.59]) by moroha.quovadx.com (8.13.6/8.13.4) with ESMTP id k66HvuBS021372 for ; Thu, 6 Jul 2006 17:57:58 GMT Received: from [10.70.3.113] ([10.70.3.113]) by qxvcexch01.ad.quovadx.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 6 Jul 2006 11:58:36 -0600 Message-ID: <44AD4F61.2000104@roguewave.com> Date: Thu, 06 Jul 2006 11:58:57 -0600 From: Martin Sebor Organization: Rogue Wave Software User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: en-us, en MIME-Version: 1.0 To: stdcxx-dev@incubator.apache.org Subject: Re: stdcxx building problem on the gcc 3.2.2/Linux RedHat9 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2006 17:58:36.0233 (UTC) FILETIME=[CDA03B90:01C6A125] X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N Farid Zaripov wrote: >>But I don't understand why a change in the order of dependencies >>makes a difference in the order of libraries on the command line. >>Can you explain it to me? > > > I don't know. > > I think it's works because used implicit rule which passes the target > dependenses to the command line Yes, that seems to match the observed behavior. I don't have a problem making the change you suggest but I would like us to understand if it works by design or if it's just a lucky happenstance. The other thing that's wrong here and that's really causing the problem is that the implicit rule is kicking in at all when an explicit rule exists. I don't understand why that happens either. I see no problem using the implicit rules (in fact I would prefer to rely on them) just as long as we do so deliberately. Right now they happen to work almost right (save for the library ordering issue), we just don't know why they are triggered. > > In command line I see that librwtest.a and libstd.a is specified > twice: > > From $(LDFLAGS): > -L/usr/src/Incubator/stdcxx/trunk/build/rwtest -lrwtest > -L/usr/src/Incubator/stdcxx/trunk/build/lib -lstd > > Appended target dependenses: > /usr/src/Incubator/stdcxx/trunk/build/lib/libstd.a > /usr/src/Incubator/stdcxx/trunk/build/rwtest/librwtest.a -lsupc++ -lm > -o 21.string.io > > And I think that LD first uses the libraries specified in the command > line directly, and only after that the libraries from -l options. UNIX linkers always process arguments left to right. Note that we don't want to specify any libraries using a full pathname. We always want to use -L flag to specify the directory and -l to name the library. That's how users will use the library so we need to make sure we build and test it the same way. This is another problem with the implicit rules that we need to understand and avoid before using them. If you're interested in looking into this here's GNU make manual: http://www.gnu.org/software/make/manual/. I suggest using the latest release of GNU make (3.81) for experimenting so as to avoid any known bugs (I've been using 3.79 but we document that versions as old as 3.70 work -- that may not be true anymore, I'm not sure). Martin