libtool & rpath
A package I maintain uses libtool. To remove the rpath stuff, I
apply this patch to configure.in. Now lintian tells me that the executables
have rpath set too! Is there an easy way to fix that?
Also, because this package (geda) includes a library, debhelper
is generating an shlibs file for it. But then the package ends up
depending on itself, because of the shlib:Depends expansion. Is there
an easy fix for that? Splitting the packages is a possibility, but
libgeda is of absolutely no use on its own yet, and I don't think there
is anything for a libgeda-dev.
thanks,
Hamish
--- geda-19981117.orig/configure.in
+++ geda-19981117/configure.in
@@ -35,6 +35,19 @@
dnl Initialize libtool
AM_PROG_LIBTOOL
+# Turn around -rpath and -lc problems with libtool 1.0c
+# This define should be improbable enough to not conflict with anything
+case ${host} in
+ *-pc-linux-gnu)
+AC_MSG_RESULT([Fixing libtool for -rpath problems.])
+sed < libtool > libtool-2 \
+ -e 's/^hardcode_libdir_flag_spec.*$/hardcode_libdir_flag_spec="
-D__LIBTOOL_IS_A_FOOL__ "/' \
+ -e '/^archive_cmds="/s/"$/ \\$deplibs"/'
+mv libtool-2 libtool
+chmod 755 libtool
+ ;;
+esac
+
dnl Initialize maintainer mode
AM_MAINTAINER_MODE
--
Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: libtool & rpath
On Wed, 27 Jan 1999, Hamish Moffatt wrote: > A package I maintain uses libtool. To remove the rpath stuff, I > apply this patch to configure.in. Now lintian tells me that the executables > have rpath set too! Is there an easy way to fix that? > > Also, because this package (geda) includes a library, debhelper > is generating an shlibs file for it. But then the package ends up > depending on itself, because of the shlib:Depends expansion. Is there > an easy fix for that? Splitting the packages is a possibility, but > libgeda is of absolutely no use on its own yet, and I don't think there > is anything for a libgeda-dev. I have found this in the policy: 4.3 Shared libraries Packages involving shared libraries should be split up into several binary packages. This suggests that the split is mandated by policy. -- "76d7bdb03d71ca6f1ed20d2f430c2567" (a truly random sig)
Re: libtool & rpath
Santiago Vila <[EMAIL PROTECTED]> writes: > On Wed, 27 Jan 1999, Hamish Moffatt wrote: > > > an easy fix for that? Splitting the packages is a possibility, but > > libgeda is of absolutely no use on its own yet, and I don't think there > > is anything for a libgeda-dev. > > I have found this in the policy: > > 4.3 Shared libraries > >Packages involving shared libraries should be split up into several >binary packages. > > This suggests that the split is mandated by policy. Actually, I think this section of policy should be reviewed. There are some limited situations (and this is one) where there is no point to have a separate shared library package, but it does make sense to compile a program with shared libraries. Martin.
Re: libtool & rpath
On Tue, Jan 26, 1999 at 02:51:03PM +0100, Santiago Vila wrote: > On Wed, 27 Jan 1999, Hamish Moffatt wrote: > > an easy fix for that? Splitting the packages is a possibility, but > > libgeda is of absolutely no use on its own yet, and I don't think there > > is anything for a libgeda-dev. > > I have found this in the policy: > > 4.3 Shared libraries > >Packages involving shared libraries should be split up into several >binary packages. > > > This suggests that the split is mandated by policy. There is absolutely no value in splitting the package at this point in time. In the future, there will be. Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: libtool & rpath
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> +case ${host} in
> + *-pc-linux-gnu)
^^
s/pc/*/ (pc==non-i386 unfriendly)
--
James
"Never trust trucks"
Re: libtool & rpath
On Wed, Jan 27, 1999 at 08:29:42PM +, James Troup wrote:
> Hamish Moffatt <[EMAIL PROTECTED]> writes:
>
> > +case ${host} in
> > + *-pc-linux-gnu)
>^^
>
> s/pc/*/ (pc==non-i386 unfriendly)
Good point. However, /usr/doc/lintian/libtool-workarounds.txt suggestions
the above, which is why I have it. No discrimination intended!
I've just started using the debian/rules version of the fix rather
than the configure.in version anyway.
Hamish
--
Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED]
Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5
CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
Re: libtool & rpath
Hamish Moffatt <[EMAIL PROTECTED]> writes:
> On Wed, Jan 27, 1999 at 08:29:42PM +, James Troup wrote:
> > Hamish Moffatt <[EMAIL PROTECTED]> writes:
> >
> > > +case ${host} in
> > > + *-pc-linux-gnu)
> >^^
> >
> > s/pc/*/ (pc==non-i386 unfriendly)
>
> Good point. However, /usr/doc/lintian/libtool-workarounds.txt suggestions
> the above [ ... ]
It was fixed in 0.9.5.
--
James
"Never trust trucks"
Re: libtool & rpath
Hamish Moffatt <[EMAIL PROTECTED]> writes: > A package I maintain uses libtool. To remove the rpath stuff, I > apply this patch to configure.in. Actually, I sort of like the following technique better: Add the following to debian/rules right before calling "$(MAKE) all" (but after configure): sed < libtool > libtool-2 \ -e 's/^hardcode_libdir_flag_spec.*$$/hardcode_libdir_flag_spec=" -D__L IBTOOL_IS_A_FOOL__ "/' \ -e '/^archive_cmds="/s/"$$/ \\$$deplibs"/' That way, there is no need to patch configure.in and rerun autoconf. > Also, because this package (geda) includes a library, debhelper > is generating an shlibs file for it. But then the package ends up > depending on itself, because of the shlib:Depends expansion. Is there > an easy fix for that? Splitting the packages is a possibility, but > libgeda is of absolutely no use on its own yet, and I don't think there > is anything for a libgeda-dev. Try: LD_LIBRARY_PATH=debian/tmp/usr/lib dh_shlibdeps -V The LD_LIBRARY_PATH prevents ldd from linking to a library that is installed on the system, so dpkg-shlibdeps doesn't find the associated package (so there is no dependency created). Cheers, - Jim
Re: libtool & rpath
On Fri, Jan 29, 1999 at 11:39:27PM -0800, Jim Pick wrote: > Hamish Moffatt <[EMAIL PROTECTED]> writes: > > > A package I maintain uses libtool. To remove the rpath stuff, I > > apply this patch to configure.in. > > Actually, I sort of like the following technique better: [...] > That way, there is no need to patch configure.in and rerun autoconf. In the past I needed other changes to configure.in, so it was the best way. I no longer need them, so I've moved the patch to debian/rules (as you suggested), which works well. > Try: > > LD_LIBRARY_PATH=debian/tmp/usr/lib dh_shlibdeps -V > > The LD_LIBRARY_PATH prevents ldd from linking to a library that > is installed on the system, so dpkg-shlibdeps doesn't find the > associated package (so there is no dependency created). Interesting solution. I decided to split the packages instead (Santiago reminds me that policy requires it presently.) This created some other problems of a similar nature but I have since sorted those out. Thanks, Hamish -- Hamish Moffatt VK3TYD [EMAIL PROTECTED], [EMAIL PROTECTED] Latest Debian packages at ftp://ftp.rising.com.au/pub/hamish. PGP#EFA6B9D5 CCs of replies from mailing lists are welcome. http://hamish.home.ml.org
