| Message ID | 1359381586-11940-2-git-send-email-jengelh@inai.de |
|---|---|
| State | Not Applicable |
| Headers | show |
On Mon, Jan 28, 2013 at 02:59:41PM +0100, Jan Engelhardt wrote: > The just-built library has DT_RPATH entries to be runnable from > whereever it is. If we just install that, the distro build systems > will throw warnings like > > (Open Build Service) ERROR: RPATH > "/home/abuild/rpmbuild/BUILD/iptables-1.4.17a/libxtables/.libs" > on /home/abuild/rpmbuild/BUILDROOT/iptables-1.4.17a-0.x86_64/usr/lib64/xtables/libxt_unclean.so > is not allowed > > These RPATH entries are indeed undesired for libraries is in a system > location, which is why libtool produces another copy of the library on > installation. The makefile however missed using libtool during > installation (introduced with commit v1.4.17-1-g68e77a2). > This patch now resolves this. > > There will be extra "warnings" emitted by libtool during `make install`, > like: > > libtool: install: warning: relinking "libxt_AUDIT.la" > > This is normal (and unfixable) I prefer that distros live with that warning. Users will be annoyed by that warning for sure. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tuesday 2013-02-05 04:30, Pablo Neira Ayuso wrote: >On Mon, Jan 28, 2013 at 02:59:41PM +0100, Jan Engelhardt wrote: >> The just-built library has DT_RPATH entries to be runnable from >> whereever it is. If we just install that, the distro build systems >> will throw warnings like >> >> (Open Build Service) ERROR: RPATH >> "/home/abuild/rpmbuild/BUILD/iptables-1.4.17a/libxtables/.libs" >> on /home/abuild/rpmbuild/BUILDROOT/iptables-1.4.17a-0.x86_64/usr/lib64/xtables/libxt_unclean.so >> is not allowed >> >> These RPATH entries are indeed undesired for libraries is in a system >> location, which is why libtool produces another copy of the library on >> installation. The makefile however missed using libtool during >> installation (introduced with commit v1.4.17-1-g68e77a2). >> This patch now resolves this. >> >> There will be extra "warnings" emitted by libtool during `make install`, >> like: >> >> libtool: install: warning: relinking "libxt_AUDIT.la" >> >> This is normal (and unfixable) > >I prefer that distros live with that warning. It is not just a warning that distros have to face. It's a complete abort of the build. >Users will be annoyed by that warning for sure. No they won't. They know libtool, they know what to expect. But whatever, I can add --no-warn, at the expensive of people who like to know what is going on. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Tue, Feb 05, 2013 at 04:30:07AM +0100, Pablo Neira Ayuso wrote: > On Mon, Jan 28, 2013 at 02:59:41PM +0100, Jan Engelhardt wrote: > > The just-built library has DT_RPATH entries to be runnable from > > whereever it is. If we just install that, the distro build systems > > will throw warnings like > > > > (Open Build Service) ERROR: RPATH > > "/home/abuild/rpmbuild/BUILD/iptables-1.4.17a/libxtables/.libs" > > on /home/abuild/rpmbuild/BUILDROOT/iptables-1.4.17a-0.x86_64/usr/lib64/xtables/libxt_unclean.so > > is not allowed > > > > These RPATH entries are indeed undesired for libraries is in a system > > location, which is why libtool produces another copy of the library on > > installation. The makefile however missed using libtool during > > installation (introduced with commit v1.4.17-1-g68e77a2). > > This patch now resolves this. > > > > There will be extra "warnings" emitted by libtool during `make install`, > > like: > > > > libtool: install: warning: relinking "libxt_AUDIT.la" > > > > This is normal (and unfixable) > > I prefer that distros live with that warning. Users will be annoyed by > that warning for sure. There is a clear misunderstanding on your side, a RPATH entry containing buildroot is a FATAL ERROR that distro maintainers have to fix just to release new builds of iptables package. The question is how long distro maintainers would have to reinvent the wheel and rebase these build fixes onto new iptables releases. To be honest, I was much surprised to find out that these build fixes didn't get into 1.4.18. With regards to libtool's warnings about relinking, it happens to all hundreds of packages that manipulate RPATH entries during build, so the amount of annoyance among libtool users would hardly increase.
On Wednesday 2013-03-06 12:08, Dmitry V. Levin wrote: >> > >> > There will be extra "warnings" emitted by libtool during `make install`, >> > like: >> > >> > libtool: install: warning: relinking "libxt_AUDIT.la" >> > >> > This is normal (and unfixable) >> >> I prefer that distros live with that warning. Users will be annoyed by >> that warning for sure. > >[...] >With regards to libtool's warnings about relinking, it happens to all >hundreds of packages that manipulate RPATH entries during build, so >the amount of annoyance among libtool users would hardly increase. That said, the --no-warn option is only available in libtool >= 2.4.2 or so; it is not present in 2.4(.0). I nevertheless have a patch (unpushed) ontop of my latest set (pushed). -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Wed, Mar 06, 2013 at 03:08:36PM +0400, Dmitry V. Levin wrote: [...] > With regards to libtool's warnings about relinking, it happens to all > hundreds of packages that manipulate RPATH entries during build, so > the amount of annoyance among libtool users would hardly increase. The thing is that the libtool patch for iptables was introduced to resolve a linking problem in ip6t_NETMAP. That could have been easily fixed with a little patch by using xtables_ip6mask_to_cidr. I'm going to post a patch to fix that linking issue that way and roll back to the previous situation where we were not using libtool. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in index adad4d6..e520c86 100644 --- a/extensions/GNUmakefile.in +++ b/extensions/GNUmakefile.in @@ -49,6 +49,9 @@ pf6_build_mod := $(filter-out @blacklist_modules@,${pf6_build_mod}) pfx_objs := $(patsubst %,libxt_%.o,${pfx_build_mod}) pf4_objs := $(patsubst %,libipt_%.o,${pf4_build_mod}) pf6_objs := $(patsubst %,libip6t_%.o,${pf6_build_mod}) +pfx_lalibs := $(patsubst %,libxt_%.la,${pfx_build_mod}) +pf4_lalibs := $(patsubst %,libipt_%.la,${pf4_build_mod}) +pf6_lalibs := $(patsubst %,libip6t_%.la,${pf6_build_mod}) pfx_solibs := $(patsubst %,libxt_%.so,${pfx_build_mod} ${pfx_symlinks}) pf4_solibs := $(patsubst %,libipt_%.so,${pf4_build_mod}) pf6_solibs := $(patsubst %,libip6t_%.so,${pf6_build_mod}) @@ -63,7 +66,8 @@ targets_install := @ENABLE_STATIC_TRUE@ libext4_objs := ${pf4_objs} @ENABLE_STATIC_TRUE@ libext6_objs := ${pf6_objs} @ENABLE_STATIC_FALSE@ targets += ${pfx_solibs} ${pf4_solibs} ${pf6_solibs} -@ENABLE_STATIC_FALSE@ targets_install += ${pfx_solibs} ${pf4_solibs} ${pf6_solibs} +@ENABLE_STATIC_FALSE@ targets_la_install += ${pfx_lalibs} ${pf4_lalibs} ${pf6_lalibs} +@ENABLE_STATIC_FALSE@ targets_so_install += ${pfx_solibs} .SECONDARY: @@ -71,9 +75,11 @@ targets_install := all: ${targets} -install: ${targets_install} +install: ${targets_la_install} ${targets_so_install} @mkdir -p "${DESTDIR}${xtlibdir}"; - if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi; + ${AM_VERBOSE_NULL} ../libtool ${AM_LIBTOOL_SILENT} --mode=install install -pm0755 ${targets_la_install} "${DESTDIR}${xtlibdir}/" + rm -f "${DESTDIR}${xtlibdir}"/*.la; + install -pm0755 ${targets_so_install} "${DESTDIR}${xtlibdir}/" clean: rm -f *.la *.o *.lo *.so *.a {matches,targets}.man initext.c initext4.c initext6.c; @@ -94,7 +100,7 @@ lib%.so: lib%.la ${AM_VERBOSE_NULL} ln -fs .libs/$@ $@ lib%.la: lib%.lo - ${AM_VERBOSE_CCLD} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=link ${CCLD} ${AM_LDFLAGS} -module ${LDFLAGS} -o $@ $< ../libxtables/libxtables.la ${$*_LIBADD} -rpath ${xtlibdir} + ${AM_VERBOSE_CCLD} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=link ${CCLD} ${AM_LDFLAGS} -avoid-version -module ${LDFLAGS} -o $@ $< ../libxtables/libxtables.la ${$*_LIBADD} -rpath ${xtlibdir} lib%.lo: ${srcdir}/lib%.c ${AM_VERBOSE_CC} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=compile ${CC} ${AM_CPPFLAGS} ${AM_DEPFLAGS} ${AM_CFLAGS} -D_INIT=lib$*_init ${CFLAGS} -o $@ -c $<
The just-built library has DT_RPATH entries to be runnable from whereever it is. If we just install that, the distro build systems will throw warnings like (Open Build Service) ERROR: RPATH "/home/abuild/rpmbuild/BUILD/iptables-1.4.17a/libxtables/.libs" on /home/abuild/rpmbuild/BUILDROOT/iptables-1.4.17a-0.x86_64/usr/lib64/xtables/libxt_unclean.so is not allowed These RPATH entries are indeed undesired for libraries is in a system location, which is why libtool produces another copy of the library on installation. The makefile however missed using libtool during installation (introduced with commit v1.4.17-1-g68e77a2). This patch now resolves this. There will be extra "warnings" emitted by libtool during `make install`, like: libtool: install: warning: relinking "libxt_AUDIT.la" This is normal (and unfixable), and is because ${builddir}/libxt_AUDIT.so links against "/home/user/iptables/libxtables/.libs/libxtables.so.9", which is correct for everything in the build tree, but for installation, "libxtables.so.9" is the right value for the DT_NEEDED entry, which is why libtool has to, and will accordingly, relink on installation. Signed-off-by: Jan Engelhardt <jengelh@inai.de> --- extensions/GNUmakefile.in | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-)