Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (herse.apache.org: local policy)
Message-ID: <45A29C3D.8000302@rowe-clan.net>
Date: Mon, 08 Jan 2007 13:32:13 -0600
From: "William A. Rowe, Jr." <wrowe@rowe-clan.net>
User-Agent: Thunderbird 1.5.0.8 (X11/20061107)
MIME-Version: 1.0
To: "William A. Rowe, Jr." <wrowe@rowe-clan.net>,  dev@httpd.apache.org,
 dev@apr.apache.org
Subject: Re: Customize lib path list (lib64 et al)?
References: <45A18BC2.2060503@rowe-clan.net>
 <20070108100023.GA4408@redhat.com>
In-Reply-To: <20070108100023.GA4408@redhat.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Joe Orton wrote:
> On Sun, Jan 07, 2007 at 06:09:38PM -0600, William Rowe wrote:
>> There is a very slick feature in perl, burried quite deeply, that
>> might be useful for our users of ./configure (and apr's as well.)
>>
>> loclibpth/locincpth define the system search order
> 
> They don't, though.  The *toolchain* defines the header/library search 
> paths and there is no portable way to extract those paths from the 
> toolchain.  configure code which requires knowledge of the search paths 
> is hence inevitably broken and non-portable, and usually fails to obey 
> CPPFLAGS/LDFLAGS to boot.

Yes - but where we arbitrarily extend the toolchain's search path in our
configure script - that's where we fall into a pit.  I'm suggesting some
method to keep ourselves from shooting users in the foot.

If it's defined by the toolchain, so be it.  If you add a LDFLAGS -lpath
that's fine.  I'm suggesting, in the absence of a lib in the path, that
we not arbitrarily invent search orders throughout our .m4 detection hacks,
and make them into a unified default list that can be overridden.