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