Return-Path: Delivered-To: apmail-apr-dev-archive@www.apache.org Received: (qmail 51767 invoked from network); 11 Jun 2009 11:47:12 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Jun 2009 11:47:12 -0000 Received: (qmail 99894 invoked by uid 500); 11 Jun 2009 11:47:24 -0000 Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 99784 invoked by uid 500); 11 Jun 2009 11:47:23 -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 99776 invoked by uid 99); 11 Jun 2009 11:47:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jun 2009 11:47:23 +0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received: from [140.211.11.9] (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with SMTP; Thu, 11 Jun 2009 11:47:21 +0000 Received: (qmail 51693 invoked by uid 2161); 11 Jun 2009 11:46:49 -0000 Received: from [192.168.2.4] (euler.heimnetz.de [192.168.2.4]) by cerberus.heimnetz.de (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 434DA1721C for ; Thu, 11 Jun 2009 13:46:50 +0200 (CEST) Message-ID: <4A30EEB3.5060905@apache.org> Date: Thu, 11 Jun 2009 13:46:59 +0200 From: Ruediger Pluem User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.21) Gecko/20090402 SeaMonkey/1.1.16 MIME-Version: 1.0 To: APR Developer List Subject: Re: [MAINTAINER] devel/apr-gdbm-db42: apr-util 1.3.7 breaks dbd support References: <200906090316.n593GCYQ075516@frieza.p6m7g8.net> <1244520824.25532.88.camel@shrek.rexursive.com> <4A2DF79D.709@rowe-clan.net> <4A2E001E.4020806@p6m7g8.com> <1244531713.25532.95.camel@shrek.rexursive.com> <4A2E0CB8.1090701@p6m7g8.com> <1244532560.25532.103.camel@shrek.rexursive.com> <1244534466.25532.113.camel@shrek.rexursive.com> <4A2E6BA4.7040305@rowe-clan.net> <20090609152157.GA15723@redhat.com> <4A2E86A0.5080005@rowe-clan.net> <1244595226.25532.146.camel@shrek.rexursive.com> <1244596384.25532.150.camel@shrek.rexursive.com> <1244597651.25532.154.camel@shrek.rexursive.com> <1244600399.25532.156.camel@shrek.rexursive.com> <1244605866.25532.157.camel@shrek.rexursive.com> <1244606176.25532.160.camel@shrek.rexursive.com> <4A300159.9040303@apache.org> <1244669840.2334.4.camel@shrek.rexursive.com> <1244690506.2334.30.camel@shrek.rexursive.com> In-Reply-To: <1244690506.2334.30.camel@shrek.rexursive.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org On 06/11/2009 05:21 AM, Bojan Smojver wrote: > On Thu, 2009-06-11 at 07:37 +1000, Bojan Smojver wrote: >> I think not, because after the if/else, we still have work to do. We >> need to find the symbol for our DB engine (either from the hash or by >> dso_load), which depends on type, which can be different from call to >> call. No? > > I verified this by running testdbm in GDB. Most definitely we can have a > situation where we need to get past that point. > > In my test, I had three providers: gdbm, db and sdbm. In the first > round, drivers hash was created and gdbm was loaded as DSO and put in > the hash. After that, we used gdbm once from the hash. Next, sdbm was > already found in the hash (because it is statically linked) and used > (twice). Finally, db was loaded as DSO and put in the hash and > subsequently used from the hash. > I took another round of review again and your approach makes sense. Thanks for your further tests and explanations. Regards R�diger