Sorry for the delay.

Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> On Sun, Nov 20, 2005 at 12:25:19AM -0500, Brad wrote:
> > On Sat, Nov 19, 2005 at 09:10:33PM -0800, Jacob Meuser wrote:
> > > On Sat, Nov 19, 2005 at 09:12:36PM -0500, Brad wrote:
> > > > > 
> > > > > So whatever the library name is supposed to be, either -lfoo or - 
> > > > > lfoo-1.8 is up to the software author, most here roll their eyes at  
> > > > > versioned libnames, but we accept them... just don't symlink them.
> > > >  
> > > > Exactly, which means not removing the ability to create shared libs with
> > > > the -release tag. This is a very bad idea. Just remove the symlinking.
> > > 
> > > I strongly disagree.
> > > 
> > > for example, we'd get _only_ libldap-2.3.so.8.1.  then we'd have to
> > > change every port with -lldap to -lldap-2.3.

I believe a better way would be to have less libraries with -release
(but that may be me only).

> > Ports should already do the right thing with pkgconfig and the other
> > mechanisms. If not then they need to be fixed. Removing -release support
> > from libtool is not happening.

Nope.  There are some situations where it is necessary.

> I think this would be very common because of the comment that gets
> put into libtool just above the library_names_spec line:
> 
> <<<
> # List of archive names.  First name is the real one, the rest are links.
> # The last name is the one that the linker finds with -lNAME.
> >>>
> 
> so the -release flag doesn't effectively create "release" named
> libraries anyway, since libtool will always create a symlink without
> the release part to the "release" library.

Well, because it's a hack in a way.  For your decision, it may be helpful
to be aware of another related "hack":
http://lists.gnu.org/archive/html/libtool/2005-07/msg00028.html

Without any symlinks, this won't work well.  I do not know whether Keith
has enabled this in X, but would assume so.  It has not yet been integrated
into GNU Libtool, but we would like to do so eventually, given that it can
be made to work on as many systems as possible.

> I can see the value in having, say libfoo-1.0.so... and
> libfoo-2.0.so..., you may want to have both installed, for
> example.  but this is not possible if both are trying to
> install libfoo.so... as well, which is what libtool would do.

Well, but this nothing new.

In any case, however you decide: if you want to see the corresponding change
in upstream Libtool as well, please let us know.  Thanks.

Cheers,
Ralf

Reply via email to