libtool
[Top][All Lists]
Advanced

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

Re: Move from handcrafted makefile to libtool


From: Ralf Wildenhues
Subject: Re: Move from handcrafted makefile to libtool
Date: Mon, 18 Sep 2006 09:27:00 +0200
User-agent: Mutt/1.5.13 (2006-09-01)

Hello Stepan,

* Stepan Kasal wrote on Thu, Sep 14, 2006 at 03:36:36PM CEST:
> Hello,
>   project newt currently uses handcrafted makefiles and installs
> libnewt like this:
> 
> /usr/lib/libnewt.so.0.52.1
> /usr/lib/libnewt.so.0.52 -> libnewt.so.0.52.1

> where SONAME is libnewt.so.0.52

On which system(s)?  ;-)
(honest question: just for one system, or on several different?)

> We would like use automake with the project,

OK.

> which means libtool should be used for shared libraries.

Erm, it's certainly convenient to do so.  But nothing prevents you from
writing your hand-crafted rules for generating/installing/cleaning the
library.  (I admit it would be rather cumbersome.)

> Is there a way to get the above soname, so that current applications
> need not be recompiled?

Not on GNU/Linux, not without patching Libtool.  There has been a
similar effort a while ago, I fear it was partly my fault it wasn't
finished yet (you can wander back to the first thread to see the
proposal):
http://lists.gnu.org/archive/html/libtool/2005-08/msg00062.html

> The option -version-number seems to generate sonames in form
>       libname.so.n

It depends on the system.  Libtool has a soname_spec and a version_type
variable, both of which are involved in the form of the final soname.

As a hack you may get away with just overwriting the soname generation
in the generated libtool script (after configure).  It would probably
be easiest to just patch the ltmain.sh file installed in your package.

One plan to move away from the hack could be to wait until the next
incompatible upgrade, and then switch the naming scheme.  I don't know
how feasible that would be in your case though.

(There are also dirtier hacks available, e.g., putting in a new soname,
but adding a symlink with the old name, pointing to the new one.  Let's
just say I don't recommend this, it will cause you trouble when some
depending programs/libraries have been relinked (thus depending against
the new soname), and some haven't; also I think this is not portable,
but I don't know this for certain.)

Cheers,
Ralf




reply via email to

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