libtool
[Top][All Lists]
Advanced

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

Re: lib*.so symlink


From: Alexandre Oliva
Subject: Re: lib*.so symlink
Date: 04 Feb 2001 00:06:30 -0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley)

On Feb  3, 2001, Brian May <address@hidden> wrote:

> What might go wrong if libz.la points to the newest version, not the
> oldest version?

I can't think of any, as long as they're both the same major version.

Well, there could be a problem in case the set of dependencies of the
different versions had changed.  But this should generally change the
major version number, should the change make any difference.

> So multiple copies of the *.la file can now be installed at the one
> time, and the *.la symlink is managed in a similar way to the *.so
> symlink.

I think having the .la file as a symlink would be misleading at best.
For example, if you change the .la symlink, but fail to change the
corresponding .so symlink, you'll still get the .so linked in.

The .la file is important in two situations:

(i) when linking with a libtool library, it determines any additional
dependencies that have to be linked in.  You must make sure it
corresponds to the actual dependencies of the library you're using for
linking, as well as the one you're going to use at run-time.

(ii) when dlopening a libtool module, it determines the SONAME to be
used, as well as the dependencies that may have to be dlopened before
the library itself.  You want it to match the library you're using at
run-time.

In both cases, changing a single link, either the .so or the
.so.MAJOR, would have been enough, while changing the .la file would
generally have no effect at all.

I only see trouble in case you want to use a different major number
for linking new applications, while still using the old version for
dlopening, in case dependencies have changed.  If dependencies haven't
changed, using the .la file of the old version should just work, since
libtool will just tell the linker to link with the .so file (with -l,
actually), and everything will just work.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



reply via email to

[Prev in Thread] Current Thread [Next in Thread]