Return-Path: Delivered-To: apmail-apr-dev-archive@apr.apache.org Received: (qmail 41638 invoked by uid 500); 17 Sep 2002 14:50:38 -0000 Mailing-List: contact dev-help@apr.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list dev@apr.apache.org Received: (qmail 41617 invoked from network); 17 Sep 2002 14:50:37 -0000 X-pair-Authenticated: 66.9.75.43 Message-ID: <3D87413B.9090409@electricjellyfish.net> Date: Tue, 17 Sep 2002 10:50:35 -0400 From: Garrett Rooney User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: James Cox CC: Greg Stein , Pier Fumagalli , dev@apr.apache.org Subject: Re: library versioning name References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N James Cox wrote: >>They *remember* yes, but how do you choose *up front* which one to link >>against? >> >>With parallel versioning, I can link my "early" APR app with: >> >>$ ld ... -lapr-0 >> >>But my newfangled one does: >> >>$ ld ... -lapr-1 >> >> >>>... >>>Now, I have few binaries that I still didn't recompile that are >> >>using DB-3.3 >> >>>(I just brought them over from an old system) but when I ldd them: >> >>Yup. But try and build those *today* and have them still link against >>DB-3.3. You need the parallel install stuff. >> > > > The problem with that is that people will more than likely be building > against apr, rather than a specific apr version, as the API has nearly > solidified, etc. (i'm assuming we're not too far away from bugfix/new > feature mode). > > So this parallel install stuff is only for those who've been using APR as > it's been developing. I imagine some will port their apps to the release > release version of apr. Of course some won't too. it's also for later down the road when we release apr 2.0. > the point is that we still need the -lapr convention to work, to grab the > latest version. Is there any way we can do both? > eg, on a linux system: > > /usr/lib/libapr-#.so... (specific version) > /usr/lib/libapr.so ... (latest) > > or something similar.... can't apr-config handle this issue? as long as people are using it to generate their makefiles, then they're all set. of course, down the road when there are multiple incompatable versions of apr lying around (i don't count the ones we have now, since they're pre 1.0, and it's expected that they will break), apr-config will have to get smarter about it... -garrett