Received: (from majordom@localhost) by hyperreal.org (8.8.5/8.8.5) id DAA26342; Fri, 22 Aug 1997 03:56:30 -0700 (PDT) Received: from DECUS.Org (Topaz.DECUS.Org [192.67.173.1]) by hyperreal.org (8.8.5/8.8.5) with ESMTP id DAA26337 for ; Fri, 22 Aug 1997 03:56:27 -0700 (PDT) Received: from Master.DECUS.Org (master.process.com) by DECUS.Org (PMDF V4.2-13 #18511) id <01IMQC8JTHK08WWSKC@DECUS.Org>; Fri, 22 Aug 1997 06:56:22 EDT Date: Fri, 22 Aug 1997 06:48:49 -0400 From: coar@decus.org (Rodent of Unusual Size) Subject: Re: bug in new Makefile To: New-HTTPd@apache.org, Coar@decus.org Message-id: <97082206484943@decus.org> X-VMS-To: NH X-VMS-Cc: COAR Content-transfer-encoding: 7BIT Sender: new-httpd-owner@apache.org Precedence: bulk Reply-To: new-httpd@apache.org >From the fingers of Paul Sutton flowed the following: > >Surely there cannot be any problems building libraries since mod_proxy and >regex have always been built as libraries and linked in. Provided that the >libraries are listed in the _right_ order on the link line of course. Exactly. >> can cause problems on systems that don't do iterative loading. > >Do you mean doing makes in successive sub-directories? No, I mean circular searching of symbol tables until either all unresolved references are located or determined to be missing. Consider "cc -o a.out refsA.o libAB.a libC.a", where refsA references a symbol symA, libAB contains modules that define symA and symB, and libC contains a module that references symB. The link will fail unless the loader either registers all symbols for conditional inclusion when it processes an input file, or else does an iterative search. (It's unfortunate that I've only seen this technology on an architecture no longer under the sun. :-( So yes, the order is critical, particularly if libraries contain multiple modules. However, I completely withdraw my objection; I've been convinced that this is a Good Thing (or at least not a Bad Thing :-). #ken :-)}