libtool "no symlinked libs" patch

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

libtool "no symlinked libs" patch

Jacob Meuser
while working on an update for multimedia/mjpegtools, and adding
USE_LIBTOOL=Yes, I would get libraries where lib/libfoo.so.4.0 would
be a symlink to lib/libfoo-1.8.so.4.0, the real library.

this comes from libtool, specifically library_names_spec is set
to '${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'

if library_names_spec is set only to '${libname}${shared_ext}$versuffix',
then only lib/libfoo.so.4.0, a real library, is created.

the code in the libtool script that uses this is at line 5966.

the following patch for the libtool port changes library_names_spec
to just '${libname}${shared_ext}$versuffix'.  I patched libtool, then
uninstalled glib2 and all it's dependencies, then built on an amd64
machine graphics/gimp and all its dependencies, a lot of which now
USE_LIBTOOL (thanks marcm!).  I also built infrastructure/plist/i386
from scratch on an i386 machine.  only one port needed to be changed,
databases/openldap.  patch for PFRAG.shared, along with a little
other libtool cleanup for that port is below the libtool patch. I
am also currently running a full package build with this patch.

comments?

--
<[hidden email]>

Index: devel/libtool/Makefile
===================================================================
RCS file: /cvs/ports/devel/libtool/Makefile,v
retrieving revision 1.44
diff -u -r1.44 Makefile
--- devel/libtool/Makefile 2 Nov 2005 02:47:09 -0000 1.44
+++ devel/libtool/Makefile 14 Nov 2005 06:42:07 -0000
@@ -6,15 +6,14 @@
 
 VERSION= 1.5.20
 DISTNAME= libtool-${VERSION}
-PKGNAME= ${DISTNAME}p1
-PKGNAME-ltdl= libltdl-${VERSION}p1
+PKGNAME= ${DISTNAME}p2
+PKGNAME-ltdl= libltdl-${VERSION}p2
 CATEGORIES= devel
 MASTER_SITES= ${MASTER_SITE_GNU:=libtool/}
 
 HOMEPAGE= http://www.gnu.org/software/libtool/
 
 AUTOCONF_VERSION= 2.59
-BUILD_DEPENDS+= ${MODGNU_AUTOCONF_DEPENDS}
 
 MAINTAINER= Brad Smith <[hidden email]>
 
@@ -24,7 +23,7 @@
 PERMIT_DISTFILES_CDROM= Yes
 PERMIT_DISTFILES_FTP= Yes
 
-CONFIGURE_STYLE= gnu
+CONFIGURE_STYLE= autoconf no-autoheader
 CONFIGURE_ARGS+= ${CONFIGURE_SHARED}
 
 MULTI_PACKAGES= -ltdl
@@ -35,6 +34,9 @@
 RUN_DEPENDS+= ::devel/libtool,-ltdl
 . endif
 .endif
+
+post-patch:
+ @cp ${WRKSRC}/libtool.m4 ${WRKSRC}/acinclude.m4
 
 do-regress:
  cd ${WRKDIR}/bin && ln -sf ${LOCALBASE}/bin/autoconf-2.59 autoconf
Index: devel/libtool/patches/patch-libtool_m4
===================================================================
RCS file: devel/libtool/patches/patch-libtool_m4
diff -N devel/libtool/patches/patch-libtool_m4
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ devel/libtool/patches/patch-libtool_m4 14 Nov 2005 06:42:07 -0000
@@ -0,0 +1,12 @@
+$OpenBSD$
+--- libtool.m4.orig Sun Nov 13 14:18:51 2005
++++ libtool.m4 Sun Nov 13 14:19:12 2005
+@@ -1586,7 +1586,7 @@ openbsd*)
+     openbsd3.3 | openbsd3.3.*) need_version=yes ;;
+     *)                         need_version=no  ;;
+   esac
+-  library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
++  library_names_spec='${libname}${shared_ext}$versuffix'
+   finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
+   shlibpath_var=LD_LIBRARY_PATH
+   if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then



Index: databases/openldap/Makefile
===================================================================
RCS file: /cvs/ports/databases/openldap/Makefile,v
retrieving revision 1.59
diff -u -r1.59 Makefile
--- databases/openldap/Makefile 12 Nov 2005 18:12:06 -0000 1.59
+++ databases/openldap/Makefile 14 Nov 2005 07:22:20 -0000
@@ -4,8 +4,8 @@
 COMMENT-server= "Open source LDAP software (server)"
 
 DISTNAME= openldap-2.3.11
-FULLPKGNAME= ${DISTNAME:S/-/-client-/}p2
-PKGNAME-server= ${DISTNAME:S/-/-server-/}p2
+FULLPKGNAME= ${DISTNAME:S/-/-client-/}p3
+PKGNAME-server= ${DISTNAME:S/-/-server-/}p3
 CATEGORIES= databases net
 
 HOMEPAGE= http://www.openldap.org/
Index: databases/openldap/patches/patch-configure
===================================================================
RCS file: /cvs/ports/databases/openldap/patches/patch-configure,v
retrieving revision 1.2
diff -u -r1.2 patch-configure
--- databases/openldap/patches/patch-configure 7 Nov 2005 15:59:08 -0000 1.2
+++ databases/openldap/patches/patch-configure 14 Nov 2005 07:22:20 -0000
@@ -1,15 +1,7 @@
 $OpenBSD: patch-configure,v 1.2 2005/11/07 15:59:08 mbalmer Exp $
 --- configure.orig Wed Oct  5 20:41:09 2005
 +++ configure Tue Oct 18 14:30:27 2005
-@@ -9443,7 +9443,6 @@ openbsd*)
-     *)                         need_version=no  ;;
-   esac
-   library_names_spec='${libname}${release}${shared_ext}$versuffix ${libname}${shared_ext}$versuffix'
--  finish_cmds='PATH="\$PATH:/sbin" ldconfig -m $libdir'
-   shlibpath_var=LD_LIBRARY_PATH
-   if test -z "`echo __ELF__ | $CC -E - | grep __ELF__`" || test "$host_os-$host_cpu" = "openbsd2.8-powerpc"; then
-     case $host_os in
-@@ -34518,6 +34517,7 @@ cat confdefs.h >>conftest.$ac_ext
+@@ -34518,6 +34518,7 @@ cat confdefs.h >>conftest.$ac_ext
  cat >>conftest.$ac_ext <<_ACEOF
  /* end confdefs.h.  */
 
Index: databases/openldap/pkg/PFRAG.shared
===================================================================
RCS file: /cvs/ports/databases/openldap/pkg/PFRAG.shared,v
retrieving revision 1.29
diff -u -r1.29 PFRAG.shared
--- databases/openldap/pkg/PFRAG.shared 7 Nov 2005 15:59:08 -0000 1.29
+++ databases/openldap/pkg/PFRAG.shared 14 Nov 2005 07:22:20 -0000
@@ -1,7 +1,4 @@
 @comment $OpenBSD: PFRAG.shared,v 1.29 2005/11/07 15:59:08 mbalmer Exp $
-@lib lib/liblber-2.3.so.8.1
 @lib lib/liblber.so.8.1
-@lib lib/libldap-2.3.so.8.1
 @lib lib/libldap.so.8.1
-@lib lib/libldap_r-2.3.so.8.1
 @lib lib/libldap_r.so.8.1

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
Jacob Meuser <jakemsr <at> jakemsr.com> writes:
>
> while working on an update for multimedia/mjpegtools, and adding
> USE_LIBTOOL=Yes, I would get libraries where lib/libfoo.so.4.0 would
> be a symlink to lib/libfoo-1.8.so.4.0, the real library.

> the following patch for the libtool port changes library_names_spec
> to just '${libname}${shared_ext}$versuffix'.

What's the rationale for this patch? Pointers to bug reports and/or changes
to ld appreciated.

Cheers,
Ralf

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Wed, Nov 16, 2005 at 08:50:56AM +0000, Ralf Wildenhues wrote:

> Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> >
> > while working on an update for multimedia/mjpegtools, and adding
> > USE_LIBTOOL=Yes, I would get libraries where lib/libfoo.so.4.0 would
> > be a symlink to lib/libfoo-1.8.so.4.0, the real library.
>
> > the following patch for the libtool port changes library_names_spec
> > to just '${libname}${shared_ext}$versuffix'.
>
> What's the rationale for this patch? Pointers to bug reports and/or changes
> to ld appreciated.

hey Ralf!

the rationale is to not have symlinked libraries.  I am under the
impression that this is not desired in OpenBSD ports/packages.
I could be wrong, but I thought this "policy decision" was made
at one point.  that's why I asked for comments.

in other words, it's not addressing a bug, but a "policy decision".

I have a question for you Ralf.  shouldn't running aclocal
create/update aclocal.m4?  this doesn't seem to work for me, which
is why the port copies the patched libtool.m4 to aclocal.m4.

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
Hi Jacob,

Jacob Meuser <jakemsr <at> jakemsr.com> writes:

> On Wed, Nov 16, 2005 at 08:50:56AM +0000, Ralf Wildenhues wrote:
> > Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> > >
> > > the following patch for the libtool port changes library_names_spec
> > > to just '${libname}${shared_ext}$versuffix'.
> >
> > What's the rationale for this patch? Pointers to bug reports and/or changes
> > to ld appreciated.
>
> the rationale is to not have symlinked libraries.  I am under the
> impression that this is not desired in OpenBSD ports/packages.
> I could be wrong, but I thought this "policy decision" was made
> at one point.  that's why I asked for comments.

Could you point me to discussion about this decision (so I don't write
about stuff already beaten to death here)?  

> in other words, it's not addressing a bug, but a "policy decision".

Hmm.

> I have a question for you Ralf.  shouldn't running aclocal
> create/update aclocal.m4?  this doesn't seem to work for me, which
> is why the port copies the patched libtool.m4 to aclocal.m4.

That's weird.  Which aclocal version?  The non-ancient ones support --force
which should always update aclocal.m4.  Is the libtool.m4 in the source tree?

BTW, please Cc: me on replies, thanks (forgot that before, d'oh).

Cheers,
Ralf

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Thu, Nov 17, 2005 at 08:12:53PM +0000, Ralf Wildenhues wrote:

> Hi Jacob,
>
> Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> > On Wed, Nov 16, 2005 at 08:50:56AM +0000, Ralf Wildenhues wrote:
> > > Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> > > >
> > > > the following patch for the libtool port changes library_names_spec
> > > > to just '${libname}${shared_ext}$versuffix'.
> > >
> > > What's the rationale for this patch? Pointers to bug reports and/or changes
> > > to ld appreciated.
> >
> > the rationale is to not have symlinked libraries.  I am under the
> > impression that this is not desired in OpenBSD ports/packages.
> > I could be wrong, but I thought this "policy decision" was made
> > at one point.  that's why I asked for comments.
>
> Could you point me to discussion about this decision (so I don't write
> about stuff already beaten to death here)?  

http://marc.theaimsgroup.com/?l=openbsd-ports&m=102587389016120

not really a discussion, but IMO rather clear.  there are a few such
"remove the -release flag" patches in the ports tree, devel/guilib
for example.

of course, that post is quite old and I see now the -current libmf
installs the symlinked libs.

so I am curious myself, if this is an issue.


> > in other words, it's not addressing a bug, but a "policy decision".
>
> Hmm.
>
> > I have a question for you Ralf.  shouldn't running aclocal
> > create/update aclocal.m4?  this doesn't seem to work for me, which
> > is why the port copies the patched libtool.m4 to aclocal.m4.
>
> That's weird.  Which aclocal version?  The non-ancient ones support --force
> which should always update aclocal.m4.  Is the libtool.m4 in the source tree?

sorry, my mistake there.  I was confusing aclocal.m4 with acinclude.m4,
again.

> BTW, please Cc: me on replies, thanks (forgot that before, d'oh).

as you wish ;)

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Marc Matteo
In reply to this post by Ralf Wildenhues

On Nov 17, 2005, at 12:12 PM, Ralf Wildenhues wrote:

> Could you point me to discussion about this decision (so I don't write
> about stuff already beaten to death here)?

In OpenBSD (at least) the library name that matters is the stuff  
between the "lib" and the ".so" so libfoo.so.4.0 and libfoo-1.8.so.
4.0 are two distinctly different libraries.  Symlinking them is stupid.

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.

Marc

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Christian Weisgerber
In reply to this post by Jacob Meuser
Jacob Meuser <[hidden email]> wrote:

> while working on an update for multimedia/mjpegtools, and adding
> USE_LIBTOOL=Yes, I would get libraries where lib/libfoo.so.4.0 would
> be a symlink to lib/libfoo-1.8.so.4.0, the real library.

Isn't this simply a mistake in the way libtool is called?  The above
behavior is triggered by "-release", IIRC.

> the following patch for the libtool port changes library_names_spec
> to just '${libname}${shared_ext}$versuffix'.

So you are suggesting to remove the offending behavior from libtool
itself rather than patching Makefiles.
Hmmm.

--
Christian "naddy" Weisgerber                          [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Fri, Nov 18, 2005 at 04:22:15PM +0000, Christian Weisgerber wrote:

> Jacob Meuser <[hidden email]> wrote:
>
> > while working on an update for multimedia/mjpegtools, and adding
> > USE_LIBTOOL=Yes, I would get libraries where lib/libfoo.so.4.0 would
> > be a symlink to lib/libfoo-1.8.so.4.0, the real library.
>
> Isn't this simply a mistake in the way libtool is called?  The above
> behavior is triggered by "-release", IIRC.
>
> > the following patch for the libtool port changes library_names_spec
> > to just '${libname}${shared_ext}$versuffix'.
>
> So you are suggesting to remove the offending behavior from libtool
> itself rather than patching Makefiles.
> Hmmm.

yes.  fewer patches throughout the tree.  isn't that part of the
the point of USE_LIBTOOL?

--
<[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Brad Smith-14
In reply to this post by Marc Matteo
On Thu, Nov 17, 2005 at 08:01:11PM -0800, Marc Matteo wrote:

>
> On Nov 17, 2005, at 12:12 PM, Ralf Wildenhues wrote:
>
> >Could you point me to discussion about this decision (so I don't write
> >about stuff already beaten to death here)?
>
> In OpenBSD (at least) the library name that matters is the stuff  
> between the "lib" and the ".so" so libfoo.so.4.0 and libfoo-1.8.so.
> 4.0 are two distinctly different libraries.  Symlinking them is stupid.
>
> 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.
>
> Marc
 
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.

// Brad

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Sat, Nov 19, 2005 at 09:12:36PM -0500, Brad wrote:

> On Thu, Nov 17, 2005 at 08:01:11PM -0800, Marc Matteo wrote:
> >
> > On Nov 17, 2005, at 12:12 PM, Ralf Wildenhues wrote:
> >
> > >Could you point me to discussion about this decision (so I don't write
> > >about stuff already beaten to death here)?
> >
> > In OpenBSD (at least) the library name that matters is the stuff  
> > between the "lib" and the ".so" so libfoo.so.4.0 and libfoo-1.8.so.
> > 4.0 are two distinctly different libraries.  Symlinking them is stupid.
> >
> > 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.
> >
> > Marc
>  
> 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.

--
<[hidden email]>


Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Brad Smith-14
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:
> > On Thu, Nov 17, 2005 at 08:01:11PM -0800, Marc Matteo wrote:
> > >
> > > On Nov 17, 2005, at 12:12 PM, Ralf Wildenhues wrote:
> > >
> > > >Could you point me to discussion about this decision (so I don't write
> > > >about stuff already beaten to death here)?
> > >
> > > In OpenBSD (at least) the library name that matters is the stuff  
> > > between the "lib" and the ".so" so libfoo.so.4.0 and libfoo-1.8.so.
> > > 4.0 are two distinctly different libraries.  Symlinking them is stupid.
> > >
> > > 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.
> > >
> > > Marc
> >  
> > 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.
>
> --
> <[hidden email]>

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.

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
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:
> > > On Thu, Nov 17, 2005 at 08:01:11PM -0800, Marc Matteo wrote:
> > > >
> > > > On Nov 17, 2005, at 12:12 PM, Ralf Wildenhues wrote:
> > > >
> > > > >Could you point me to discussion about this decision (so I don't write
> > > > >about stuff already beaten to death here)?
> > > >
> > > > In OpenBSD (at least) the library name that matters is the stuff  
> > > > between the "lib" and the ".so" so libfoo.so.4.0 and libfoo-1.8.so.
> > > > 4.0 are two distinctly different libraries.  Symlinking them is stupid.
> > > >
> > > > 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.
> > > >
> > > > Marc
> > >  
> > > 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.
> >
> > --
> > <[hidden email]>
>
> 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.

using databases/openldap again as an example, this package has no
pkg-config file, no sort of openldap-config script, and no
openldap.m4 autoconf macros.

so we would have to manually patch _everything_ that uses -lldap,
30+ ports.

and with the multimedia/mjpegtools update I have,
$ pkg-config mjpegtools --libs
-L/usr/local/lib -lmjpegutils
$

but I have only libmjpegutils-1.8.so.0.0

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.

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.

the ports that do effectively have release named libraries, like
most of the gtk/gnome stuff, do not use the -release flag to build
the library names.

I built over 1000 package with the patch I proposed, including large
chunks of the gnome stuff that now does USE_LIBTOOL.  only openldap
needed to be changed, because, quite frankly, the -release tag
has already been removed from most ports that use it ... i.e.
the result is the same as the way it is now, it just changes where
and how it is done.

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
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 | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Tue, Nov 22, 2005 at 09:58:44AM +0000, Ralf Wildenhues wrote:
> Sorry for the delay.

thanks for responding.  it's good to have a libtool developer in
this discussion :)

> 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).

that is essentially the current situation in the ports tree.  there
are several patches to remove the -release flag from libtool
invocations in Makefiles.

> > > 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.

such as?  the patch I proposed only changes library_names_spec on
OpenBSD.  I wasn't really intending for that to go upstream, anyway ...

> > 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.

interesting.  not sure how this would affect OpenBSD.  currently,
there is no soname_spec in libtool for OpenBSD.  SONAME seems to be
rarely used in libraries on OpenBSD as well.

the -old-abi idea is interesting as well :)

> > 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.

true, Keith even mentioned this issue in the above thread.

there is something of a push to use a single libtool in the OpenBSD
ports tree.  that is, use the libtool from the ports tree for every
port that uses libtool.  really, OpenBSD support in libtool was not
so good until fairly recently, so there are a lot of patches for the
different libtool versions the various packages come with.  but now
that there is a libtool that works pretty well, it is a lot easier
to just use that instead of trying to patch the various libtools
that come with the various packages.

my suggestion was intended to further reduce the number of patches
for libtool related issues in the ports tree, nothing more, nothing
less.

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

now that I've thought about it a little more, I can see the value in
the -release flag from a developer's perspective.  you could have
a 1.0 release that you are maintaining, and a 1.1 release that is
in development.  you would might want to have both installed, and
just change the symlink back and forth, assuming you would want
backward compatability.  while this could be useful from a
developer's perspective, it is still a conflict from a packager's
perspective.  this doesn't seem to be how/why the -release flag is
generally used, though.

maybe the best solution would be to have an "internal" libtool,
that is hacked in ways that would be useful for building ports but
may limit overall usability/features, and a "standard" libtool port
that does not contain such hacks?  I dunno.  it's not really my
decision anyway ;P

> Cheers,
> Ralf

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Marc Espie-2
As far as OpenBSD goes, we solve the `various versions' issue differently.

- we have kept the version numbers from old a.out. Our ELF ld.so knows
about libfoo.so.major.minor.
- if we want several versions installed, it's just a question of having
them in distinct directories. ld stops at the first directory where it
finds a library.

So, for instance, if you have both qt2 and qt3 installed, you end up with
libqt.so.2.0 and libqt.so.3.0 in /usr/local/lib (since ld.so looks at
/usr/local by default), and for linking, you have them visible as
/usr/local/lib/qt2/libqt.so.2.0 and /usr/local/lib/qt3/libqt.so.3.0.

This is how it's supposed to work for us...

We don't need more version numbers to develop with the right stuff.
And we don't use sonames too much, even though yes, we support them.

Having everything visible upfront in the library names is simpler for us.

We have also had a few cases where we want to have control on the major
version number: changes in system libraries, the C or the C++ library, for
instance, mean that the major number of a few libraries also need to change,
because some include file or another was changed.

The current automake/libtool mechanism is just fine for this, since we just
need to override one variable from the command line.


In reality, our biggest (read: very large) peeve with libtool is that it
parses too much of gcc internals, and too little at the same time.

I'm very annoyed at
libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la
expanding into some stuff like:
cc -L/usr/local/lib -L. -o foo foo.o -lbar
which gets us the libbar installed under /usr/local/lib instead of the one
we just built...

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
In reply to this post by Jacob Meuser
[ please excuse gmane web interface-induced quote wrapping ]

Jacob Meuser <jakemsr <at> jakemsr.com> writes:
> On Tue, Nov 22, 2005 at 09:58:44AM +0000, Ralf Wildenhues wrote:
> > Sorry for the delay.
>
> thanks for responding.  it's good to have a libtool developer in
> this discussion :)

Although I must confess that I usually know a lot less about the target
platform than the respective maintainers.
Thanks BTW to Thorsten Glaser for pointing me to this discussion.

> > 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:
> > > > >
> > > > > 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).
>
> that is essentially the current situation in the ports tree.  there
> are several patches to remove the -release flag from libtool
> invocations in Makefiles.

OK.

> > > > 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.
>
> such as?  the patch I proposed only changes library_names_spec on
> OpenBSD.  I wasn't really intending for that to go upstream, anyway ...

OK.  Good to know.

> > > 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.
>
> interesting.  not sure how this would affect OpenBSD.  currently,
> there is no soname_spec in libtool for OpenBSD.  SONAME seems to be
> rarely used in libraries on OpenBSD as well.

I did not know the linker does not mind if no file or symlink named
SONAME existed.

> the -old-abi idea is interesting as well :)

Yep.

> there is something of a push to use a single libtool in the OpenBSD
> ports tree.  that is, use the libtool from the ports tree for every
> port that uses libtool.  really, OpenBSD support in libtool was not
> so good until fairly recently, so there are a lot of patches for the
> different libtool versions the various packages come with.  but now
> that there is a libtool that works pretty well, it is a lot easier
> to just use that instead of trying to patch the various libtools
> that come with the various packages.

Well, that's good to hear.  I really like to reduce the number of Libtool
patches floating around, and I would like to have decent support for as many
systems as possible (and just to mention it again, support for BSD systems
should be just as good as for any other system).  Luckily some of the patches
can go when we finally manage to get Libtool-2.0 out the door.

> my suggestion was intended to further reduce the number of patches
> for libtool related issues in the ports tree, nothing more, nothing
> less.

All good.  It may be less patches for you to change libtool.m4 than to
remove the -release flags, but as you say:

> > In any case, however you decide: if you want to see the corresponding change
> > in upstream Libtool as well, please let us know.  Thanks.
>
> now that I've thought about it a little more, I can see the value in
> the -release flag from a developer's perspective.  you could have
> a 1.0 release that you are maintaining, and a 1.1 release that is
> in development.  you would might want to have both installed, and
> just change the symlink back and forth, assuming you would want
> backward compatability.

Exactly.  Same thing with different -version-info flags.

> while this could be useful from a
> developer's perspective, it is still a conflict from a packager's
> perspective.  this doesn't seem to be how/why the -release flag is
> generally used, though.

No, the -release flag is bad in that it should not be the package version
that makes up the library version.  Many developers don't understand this,
however.

> maybe the best solution would be to have an "internal" libtool,
> that is hacked in ways that would be useful for building ports but
> may limit overall usability/features, and a "standard" libtool port
> that does not contain such hacks?  I dunno.  it's not really my
> decision anyway ;P

OK with me.  I'm merely interested in "internal" libtool changes insofar
as I would like to prevent those changes to break users who try to build
their "standard" libtoolized package, even on OpenBSD.  Call it violent
agreement if you like. :)

Cheers,
Ralf

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
In reply to this post by Marc Espie-2
Marc Espie <espie <at> nerim.net> writes:
>
> As far as OpenBSD goes, we solve the `various versions' issue differently.
>
> - we have kept the version numbers from old a.out. Our ELF ld.so knows
> about libfoo.so.major.minor.

I have a hard time to learn this from the manpages, by the way.

> - if we want several versions installed, it's just a question of having
> them in distinct directories. ld stops at the first directory where it
> finds a library.

I may need more information in order to be able to fix the bug you describe
later.  Could you just point me to the CVS files that implement the ld
and the ld.so search algorithms?  Thanks.

> So, for instance, if you have both qt2 and qt3 installed, you end up with
> libqt.so.2.0 and libqt.so.3.0 in /usr/local/lib (since ld.so looks at
> /usr/local by default), and for linking, you have them visible as
> /usr/local/lib/qt2/libqt.so.2.0 and /usr/local/lib/qt3/libqt.so.3.0.
>
> This is how it's supposed to work for us...

Ah, ok.
 
> We don't need more version numbers to develop with the right stuff.
> And we don't use sonames too much, even though yes, we support them.

Again, to work on Keith's proposal for OpenBSD, I'd need more information
here.

> Having everything visible upfront in the library names is simpler for us.

Sure.

> We have also had a few cases where we want to have control on the major
> version number: changes in system libraries, the C or the C++ library, for
> instance, mean that the major number of a few libraries also need to change,
> because some include file or another was changed.

Sure.

> The current automake/libtool mechanism is just fine for this, since we just
> need to override one variable from the command line.

OK

> In reality, our biggest (read: very large) peeve with libtool is that it
> parses too much of gcc internals, and too little at the same time.

I assume this (above) is not about quite the same bug as this below(?):

> I'm very annoyed at
> libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la
> expanding into some stuff like:
> cc -L/usr/local/lib -L. -o foo foo.o -lbar
> which gets us the libbar installed under /usr/local/lib instead of the one
> we just built...

Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption
about which path overrides which.  Current branch-1-5 does not do this on
GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD.
For static libbar, it creates on both systems
  gcc -o foo foo.o  ./.libs/libbar.a
and for shared libbar it creates
  gcc -o .libs/foo foo.o  ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst

In both cases executing ./foo picks up the new library.  There was a bugfix
after 1.5.20 which before caused the shell wrapper (in the shared case) to
miss setting all environment variables correctly, so really the CVS version
may be needed.  We hope to have an 1.5.22 release very very soon.

If you still get this bug, and it is not exposed by the libtool testsuite,
please let me know.  Writing a test for it is pretty trivial (in fact I can
provide the one I just used to provide this very answer).  If you can provide
more information (see above) or even a login where I can test, I should be
able to fix this myself, given some spare time.

Cheers,
Ralf

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Jacob Meuser
On Wed, Nov 23, 2005 at 05:04:07PM +0000, Ralf Wildenhues wrote:
> Marc Espie <espie <at> nerim.net> writes:

> > I'm very annoyed at
> > libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la
> > expanding into some stuff like:
> > cc -L/usr/local/lib -L. -o foo foo.o -lbar
> > which gets us the libbar installed under /usr/local/lib instead of the one
> > we just built...
>
> Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption
> about which path overrides which.  Current branch-1-5 does not do this on
> GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD.
>
> For static libbar, it creates on both systems
>   gcc -o foo foo.o  ./.libs/libbar.a
> and for shared libbar it creates
>   gcc -o .libs/foo foo.o  ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst

I think you are not understanding Marc's point.  what happens with
-L/usr/local/lib?

anyway, I think a more likely scenerio would be something like:

/bin/sh ./libtool --tag=CC --mode=link -L/usr/X11R6/lib -o foo foo-foo.o lib/libbar.la -lX11

the problem is that -L/usr/X11R6/lib will come before -Llib/.libs in the compile_cmd.

however, if the command were given as:

/bin/sh ./libtool --tag=CC --mode=link -o foo foo-foo.o lib/libbar.la -L/usr/X11R6/lib -lX11

then the library include paths would be -Llib/.libs -L/usr/X11R6/lib,
which is the desired order.  this can be blamed to some degree on automake.
if you have this in a Makefile.am:

foo_SOURCES = foo.c
foo_LDADD = lib/libbar.la -lX11 -lXv
foo_DEPENDENCIES = lib/libbar.la
foo_CPPFLAGS = -I/usr/X11R6/include
foo_LDFLAGS = -L/usr/X11R6/lib

then you will get a link command like so in Makefile:

LINK = $(LIBTOOL) --tag=CC --mode=link $(CCLD) $(AM_CFLAGS) $(CFLAGS) \
        $(AM_LDFLAGS) $(LDFLAGS) -o $@

foo$(EXEEXT): $(foo_OBJECTS) $(foo_DEPENDENCIES)
        @rm -f foo$(EXEEXT)
        $(LINK) $(foo_LDFLAGS) $(foo_OBJECTS) $(foo_LDADD) $(LIBS)

so you end up with the local, newly created libraries coming after all
possible LDFLAGS in the libtool command.  at least this is what happens with
automake-1.9.6.

the real question is, IMO, how would libtool know what are local, new
libraries?

think of this:

/bin/sh ./libtool --tag=CC --mode=link -o foo foo-foo.o /usr/local/lib/libglib-2.0.la $(top_builddir)lib/libbar.la -L/usr/X11R6/lib -lX11

there are two libtool libraries, both with full paths on the command line.
how would libtool know the path to one should come before the path to
the other?

seems to me that straightening this out would require major changes to
both libtool and automake.

--
<[hidden email]>

Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
Hi Jacob,

* Jacob Meuser wrote on Sun, Nov 27, 2005 at 05:42:07AM CET:

> On Wed, Nov 23, 2005 at 05:04:07PM +0000, Ralf Wildenhues wrote:
> > Marc Espie <espie <at> nerim.net> writes:
>
> > > I'm very annoyed at
> > > libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la
> > > expanding into some stuff like:
> > > cc -L/usr/local/lib -L. -o foo foo.o -lbar
> > > which gets us the libbar installed under /usr/local/lib instead of the one
> > > we just built...
> >
> > Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption
> > about which path overrides which.  Current branch-1-5 does not do this on
> > GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD.
> >
> > For static libbar, it creates on both systems
> >   gcc -o foo foo.o  ./.libs/libbar.a
> > and for shared libbar it creates
> >   gcc -o .libs/foo foo.o  ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst
>
> I think you are not understanding Marc's point.
No, but I pasted the output in a misleading way.

> what happens with -L/usr/local/lib?

Libtool knows that the library is uninstalled, because this information
is encoded in libbar.la, hence knows to hardcode it _even_ when the
installed path is given first.  Attached an example.  Please modify so
it fails on OpenBSD.  Elsewhere it creates

gcc -o .libs/main main.o  -L/tmp/inst/lib ./.libs/liba.so \
  -Wl,--rpath -Wl,/tmp/inst/lib

Now please: be specific in the bug report, and state exactly which
libtool version you are using (including which patches you have
applied) and post all output.  Also please show 'libtool --config'.

I am pretty sure our testsuite covers this, too.  Any failures on
OpenBSD?  (Please run with VERBOSE=x so one can see actually useful
output.)

Cheers,
Ralf

run.sh (757 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: libtool "no symlinked libs" patch

Ralf Wildenhues
[ Cc: to libtool mailing list.  This thread is at
  http://thread.gmane.org/gmane.os.openbsd.ports/14993
  and the interesting bit starts at the end of this post:
  http://article.gmane.org/gmane.os.openbsd.ports/15121 ]

* Ralf Wildenhues wrote on Sun, Nov 27, 2005 at 09:06:09AM CET:

> * Jacob Meuser wrote on Sun, Nov 27, 2005 at 05:42:07AM CET:
> > On Wed, Nov 23, 2005 at 05:04:07PM +0000, Ralf Wildenhues wrote:
> > > Marc Espie <espie <at> nerim.net> writes:
> >
> > > > I'm very annoyed at
> > > > libtool --mode=link cc -L/usr/local/lib -o foo foo.o ./libbar.la
> > > > expanding into some stuff like:
> > > > cc -L/usr/local/lib -L. -o foo foo.o -lbar
> > > > which gets us the libbar installed under /usr/local/lib instead of the one
> > > > we just built...
> > >
> > > Genuine bug in Libtool's OpenBSD support, most likely some wrong assumption
> > > about which path overrides which.  Current branch-1-5 does not do this on
> > > GNU/Linux nor on FreeBSD -- sorry, I don't currently have access to OpenBSD.
> > >
> > > For static libbar, it creates on both systems
> > >   gcc -o foo foo.o  ./.libs/libbar.a
> > > and for shared libbar it creates
> > >   gcc -o .libs/foo foo.o  ./.libs/libbar.so -Wl,--rpath -Wl,/tmp/inst
> >
> > I think you are not understanding Marc's point.
>
> No, but I pasted the output in a misleading way.
>
> > what happens with -L/usr/local/lib?
>
> Libtool knows that the library is uninstalled, because this information
> is encoded in libbar.la, hence knows to hardcode it _even_ when the
> installed path is given first.  Attached an example.  Please modify so
> it fails on OpenBSD.

OK.  This fails on OpenBSD because of hardcode_direct=yes, all branches,
I assume, because then libtool will create
  cc -L/usr/local/lib -L.libs ..
then.

Call for help: I need access to an OpenBSD box or someone with access to
help me debug this (off-list), because the failure is not exposed with
GNU ld.

Cheers,
Ralf

12