Mailing-List: contact dev-help@apr.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (hermes.apache.org: domain of jorton@redhat.com designates
 66.187.233.31 as permitted sender)
Date: Sun, 29 Aug 2004 19:27:31 +0100
From: Joe Orton <jorton@redhat.com>
To: dev@apr.apache.org
Subject: Re: make install doesn't update the .so.0 symlink
Message-ID: <20040829182731.GA10711@redhat.com>
Mail-Followup-To: dev@apr.apache.org
References: <413209CE.3070303@stason.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <413209CE.3070303@stason.org>
User-Agent: Mutt/1.4.1i

On Sun, Aug 29, 2004 at 12:52:30PM -0400, Stas Bekman wrote:
> It took me a while to figure out what was the problem with some 3rd party 
> library using libapr. Eventually I've discovered that the libapr-0.so.0 
> symlink wasn't getting updated on 'make install', the old link to an older 
> library was kept intact. Is it a bug?
> 
> /home/stas/httpd/prefork/lib> ls -l libapr-0.so.0
> lrwxrwxrwx  1 stas stas 17 Aug 29 12:34 libapr-0.so.0 -> libapr-0.so.0.9.5
> /home/stas/httpd/prefork/lib> cp libapr-0.so.0.9.5 libapr-0.so.0.9.5-old

This is an artificial test case - what's the real failure? An upgrade
from what to what is behaving like this?

What's happening in the above case is that the libtool install mode runs
ldconfig -n for that directory, and ldconfig updates the symlinks to
point to the "latest" version available as appropriate, where it
presumes that 0.9.5-old is a greater version than 0.9.5.

joe