[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: neon026 and .la files



Hi Peter,

On Tue, Dec 05, 2006 at 03:27:04PM -0600, Peter Samuelson wrote:
> [Joe Orton]
> > `neon-config --la-file` is part of the defined and documented neon
> > interface: removing the .la file breaks that interface, and hence
> > will break applications designed to build against neon.
> 
> So, I was the one who requested that the neon26 maintainer remove the
> .la file.  I'll incorporate Ondrej and Steve's comments by reference
> here - suffice it to say Debian has good reasons to want to phase out
> .la files entirely, if possible.

Debian has good reasons to want to avoid propagating unnecessary shared 
library dependencies.  You can achieve that goal using a trival sed 
command for neon:

  sed -i "s/^\(dependency_libs\).*/\1='-lneon'/" libneon.la

which avoids breaking the neon interface.  This is correct for current 
versions of neon iff you don't care about supporting static linking via 
the .la file.

For libraries where the API of dependencies may leak through to the 
application, naively removing the .la file hides *necessary* shared 
library dependencies, which is simply unsafe.  That's why the only safe 
way to fix this problem in general is at libtool level, as I mentioned 
before.

(there are several cases in libraries I deal with: Subversion leaks the 
APR API, APR-util leaks the OpenLDAP API, OpenLDAP and PostgreSQL both 
leak the OpenSSL API)

> As for 'neon-config --la-file', I am curious why it even exists.  Is 
> not 'neon-config --libs' just as effective?

Using the .la file is unambigious in cases where you have more than one 
libneon.so in the library path; libtool will link against the correct 
.so using an absolute path if given the absolute path to the .la, which 
cannot be achieved in the general case using --libs.

Regards,

joe



Reply to: