Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 1336 invoked from network); 11 Oct 2010 14:18:43 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 11 Oct 2010 14:18:43 -0000 Received: (qmail 78373 invoked by uid 500); 11 Oct 2010 14:18:42 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 78010 invoked by uid 500); 11 Oct 2010 14:18:40 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Id: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 78001 invoked by uid 99); 11 Oct 2010 14:18:39 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 14:18:39 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=10.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rainer.jung@kippdata.de designates 195.227.30.149 as permitted sender) Received: from [195.227.30.149] (HELO mailserver.kippdata.de) (195.227.30.149) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 11 Oct 2010 14:18:31 +0000 Received: from [195.227.30.209] (notebook-rj [195.227.30.209]) by mailserver.kippdata.de (8.13.5/8.13.5) with ESMTP id o9BEIA7K008919 for ; Mon, 11 Oct 2010 16:18:10 +0200 (CEST) Message-ID: <4CB31C9C.5020700@kippdata.de> Date: Mon, 11 Oct 2010 16:18:04 +0200 From: Rainer Jung User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.9) Gecko/20100915 Thunderbird/3.1.4 MIME-Version: 1.0 To: APR Developer List Subject: Re: [VOTE] Release apr-0.9.19 and/or apr-util-0.9.18 References: <54AA3581-5CC5-49BC-8D8F-930F475026CD@temme.net><4CB2DA7C.5050802@kippdata.de> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit On 11.10.2010 15:59, Eric Covener wrote: >>> Seems that our 0.9.18 build is looking in the wrong place. This is a >>> regression: -1. >>> >>> Has anyone else tested with bundled Expat? > > I had tested with explicit --with-expat=bundled, I am seeing when > there is no system expat (and configure discovers the bundled expat) > it has the extra /lib/ subdirs in it. "It has in it": where? It is ncluded in the path APRUTIL_LDFLAGS, but those are actually not really used (only for make check and even there it works with the wrong path). I also do use "--with-expat=builtin", not the "no system expat so use bundled one" detection. > Weirdly when I retested this implicit way, and could see the "bad" > path in config.log, nothing was actually broken. Would be interesting, which lines of config.log. For Sander's build it seems libaprutil gets actually linked against libexpat explicitely (and then libexpat is looked for in the wrong directory). My Unix/Linux builds do not link libaprutil explicitely against libexpat (neither for recent apr-util, not for earlier 0.9 releases). This differs from 1.3, where libaprutil is linked against libexpat. Regards, Rainer