[PATCH] build: resolve link failure for ip6t_NETMAP

[PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

Link stage of libip6t_NETMAP failed since recently.

  CCLD     libip6t_NETMAP.so
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
cannot find -lip6tc

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---

Retrievable through
	git://git.inai.de/iptables master


 extensions/GNUmakefile.in |    3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in
index e71e3ff..68e0b9b 100644
--- a/extensions/GNUmakefile.in
+++ b/extensions/GNUmakefile.in
@@ -101,7 +101,8 @@ libxt_state.so: libxt_conntrack.so
 	ln -fs $< $@
 
 # Need the LIBADDs in iptables/Makefile.am too for libxtables_la_LIBADD
-ip6t_NETMAP_LIBADD  = -lip6tc
+ip6t_NETMAP_LIBADD  = -L${top_builddir}/libiptc/.libs \
+                      -L${top_builddir}/libiptc -lip6tc
 xt_RATEEST_LIBADD   = -lm
 xt_statistic_LIBADD = -lm
 
-- 
1.7.10.4

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Pablo Neira Ayuso]

On Sun, Dec 02, 2012 at 07:16:48PM +0100, Jan Engelhardt wrote:
> Link stage of libip6t_NETMAP failed since recently.
> 
>   CCLD     libip6t_NETMAP.so
> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
> cannot find -lip6tc

Is this problem opensuse specific? Need some diagnosing information on
why that's happening.

> Signed-off-by: Jan Engelhardt <jengelh@inai.de>
> ---
> 
> Retrievable through
> 	git://git.inai.de/iptables master
> 
> 
>  extensions/GNUmakefile.in |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in
> index e71e3ff..68e0b9b 100644
> --- a/extensions/GNUmakefile.in
> +++ b/extensions/GNUmakefile.in
> @@ -101,7 +101,8 @@ libxt_state.so: libxt_conntrack.so
>  	ln -fs $< $@
>  
>  # Need the LIBADDs in iptables/Makefile.am too for libxtables_la_LIBADD
> -ip6t_NETMAP_LIBADD  = -lip6tc
> +ip6t_NETMAP_LIBADD  = -L${top_builddir}/libiptc/.libs \
> +                      -L${top_builddir}/libiptc -lip6tc
>  xt_RATEEST_LIBADD   = -lm
>  xt_statistic_LIBADD = -lm
>  
> -- 
> 1.7.10.4
> 
> --
> 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

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

On Monday 2012-12-03 14:12, Pablo Neira Ayuso wrote:

>On Sun, Dec 02, 2012 at 07:16:48PM +0100, Jan Engelhardt wrote:
>> Link stage of libip6t_NETMAP failed since recently.
>> 
>>   CCLD     libip6t_NETMAP.so
>> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
>> cannot find -lip6tc
>
>Is this problem opensuse specific? Need some diagnosing information on
>why that's happening.

This happens whenever you don't have /usr/lib(64)/libip6tc.so.

In openSUSE, iptables is split into the packages iptables, libiptc0, 
libiptc-devel, libxtables9 and libxtables-devel, and libip6tc.so is a 
-devel thing that is generally not installed on user's machines. (Hence 
I spot this.) I think this should be similar in Debian.

Also, note that iptables itself is not installed while building iptables 
itself (for obvious reasons) in most distribution build systems.

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Pablo Neira Ayuso]

On Mon, Dec 03, 2012 at 04:58:11PM +0100, Jan Engelhardt wrote:
> On Monday 2012-12-03 14:12, Pablo Neira Ayuso wrote:
> 
> >On Sun, Dec 02, 2012 at 07:16:48PM +0100, Jan Engelhardt wrote:
> >> Link stage of libip6t_NETMAP failed since recently.
> >> 
> >>   CCLD     libip6t_NETMAP.so
> >> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
> >> cannot find -lip6tc
> >
> >Is this problem opensuse specific? Need some diagnosing information on
> >why that's happening.
> 
> This happens whenever you don't have /usr/lib(64)/libip6tc.so.
> 
> In openSUSE, iptables is split into the packages iptables, libiptc0, 
> libiptc-devel, libxtables9 and libxtables-devel, and libip6tc.so is a 
> -devel thing that is generally not installed on user's machines. (Hence 
> I spot this.) I think this should be similar in Debian.
> 
> Also, note that iptables itself is not installed while building iptables 
> itself (for obvious reasons) in most distribution build systems.

By this explanation, then I don't see why we need that -lip6tc in the
makefile.

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

On Tuesday 2012-12-04 13:16, Pablo Neira Ayuso wrote:

>On Mon, Dec 03, 2012 at 04:58:11PM +0100, Jan Engelhardt wrote:
>> On Monday 2012-12-03 14:12, Pablo Neira Ayuso wrote:
>> 
>> >On Sun, Dec 02, 2012 at 07:16:48PM +0100, Jan Engelhardt wrote:
>> >> Link stage of libip6t_NETMAP failed since recently.
>> >> 
>> >>   CCLD     libip6t_NETMAP.so
>> >> /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
>> >> cannot find -lip6tc
>> >
>> >Is this problem opensuse specific? Need some diagnosing information on
>> >why that's happening.
>> 
>> This happens whenever you don't have /usr/lib(64)/libip6tc.so.
>> 
>> In openSUSE, iptables is split into the packages iptables, libiptc0, 
>> libiptc-devel, libxtables9 and libxtables-devel, and libip6tc.so is a 
>> -devel thing that is generally not installed on user's machines. (Hence 
>> I spot this.) I think this should be similar in Debian.
>> 
>> Also, note that iptables itself is not installed while building iptables 
>> itself (for obvious reasons) in most distribution build systems.
>
>By this explanation, then I don't see why we need that -lip6tc in the
>makefile.

Without -lip6tc (the current state of the 'next' branch), it would yield 
an error:

libip6t_NETMAP.oo: In function `NETMAP_print':
/home/jengelh/code/iptables/extensions/libip6t_NETMAP.c:64: undefined 
reference to `ipv6_prefix_length'

[PATCH] extensions: fix linking against -lip6tc

[Mike Frysinger]

The current build forgets to specify a path to find libip6tc which means
it either fails (if there is no libip6tc in the system), or links against
an old version (if there is one in the system).

References: https://bugs.gentoo.org/449262
Reported-by: Mike Gilbert <floppym@gentoo.org>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
---
 extensions/GNUmakefile.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in
index e71e3ff..a605474 100644
--- a/extensions/GNUmakefile.in
+++ b/extensions/GNUmakefile.in
@@ -101,7 +101,7 @@ libxt_state.so: libxt_conntrack.so
 	ln -fs $< $@
 
 # Need the LIBADDs in iptables/Makefile.am too for libxtables_la_LIBADD
-ip6t_NETMAP_LIBADD  = -lip6tc
+ip6t_NETMAP_LIBADD  = -L../libiptc/.libs -lip6tc
 xt_RATEEST_LIBADD   = -lm
 xt_statistic_LIBADD = -lm
 
-- 
1.8.0

Re: [PATCH] extensions: fix linking against -lip6tc

[Pablo Neira Ayuso]

Hi Mike,

On Sun, Dec 30, 2012 at 06:11:47PM -0500, Mike Frysinger wrote:
> The current build forgets to specify a path to find libip6tc which means
> it either fails (if there is no libip6tc in the system), or links against
> an old version (if there is one in the system).

We already got a similar patch fix for that issue:

http://patchwork.ozlabs.org/patch/208133/

Can you give it a try and check if it also fixes the problem for you?

Thanks.

Re: [PATCH] extensions: fix linking against -lip6tc

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 856 bytes --]

On Sunday 30 December 2012 18:38:28 Pablo Neira Ayuso wrote:
> Hi Mike,
> 
> On Sun, Dec 30, 2012 at 06:11:47PM -0500, Mike Frysinger wrote:
> > The current build forgets to specify a path to find libip6tc which means
> > it either fails (if there is no libip6tc in the system), or links against
> > an old version (if there is one in the system).
> 
> We already got a similar patch fix for that issue:
> 
> http://patchwork.ozlabs.org/patch/208133/
> 
> Can you give it a try and check if it also fixes the problem for you?

adding an -L path to the non-.libs/ subdir doesn't make sense when the 
existing code (the -lxtables stuff) only uses .libs/.

really the best thing would to stop grubbing around in libtool internals and 
use libtool to link considering it was used to generate the other libraries in 
the first place.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

[PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

Link stage of libip6t_NETMAP failed since recently.

  CCLD     libip6t_NETMAP.so
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
cannot find -lip6tc

libip6t_NETMAP.c uses the "ipv6_prefix_length" function from
libip6tc.so; "-lip6tc" is used in the Makefile, but, the directory to
it is not specified.

Why does the link succeed for some people? Because
/usr/lib(64)/libip6tc.so satisfies -lip6tc, but not all environments,
especially those without iptables development files, have that file,
hence this link error can happen.

By suggestion of Mike Frysinger, this patch uses libtool to produce
and link the plugins.

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---

Like this? We cannot really get rid of mentioning .libs without involving
libltdl, and there I really do not want to go.

If you ask me, we should just move ipv6_prefix_length into libxtables.


 extensions/GNUmakefile.in |   16 ++++++++++------
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in
index e71e3ff..6020ff6 100644
--- a/extensions/GNUmakefile.in
+++ b/extensions/GNUmakefile.in
@@ -33,6 +33,7 @@ AM_VERBOSE_CXX    = @echo "  CXX     " $@;
 AM_VERBOSE_CXXLD  = @echo "  CXXLD   " $@;
 AM_VERBOSE_AR     = @echo "  AR      " $@;
 AM_VERBOSE_GEN    = @echo "  GEN     " $@;
+AM_VERBOSE_NULL   = @
 endif
 
 #
@@ -75,7 +76,7 @@ install: ${targets_install}
 	if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi;
 
 clean:
-	rm -f *.o *.oo *.so *.a {matches,targets}.man initext.c initext4.c initext6.c;
+	rm -f *.la *.o *.lo *.so *.a {matches,targets}.man initext.c initext4.c initext6.c;
 	rm -f .*.d .*.dd;
 
 distclean: clean
@@ -89,11 +90,14 @@ init%.o: init%.c
 #
 #	Shared libraries
 #
-lib%.so: lib%.oo
-	${AM_VERBOSE_CCLD} ${CCLD} ${AM_LDFLAGS} -shared ${LDFLAGS} -o $@ $< -L../libxtables/.libs -lxtables ${$*_LIBADD};
+lib%.so: lib%.la
+	${AM_VERBOSE_NULL} ln -fs .libs/$@ $@;
 
-lib%.oo: ${srcdir}/lib%.c
-	${AM_VERBOSE_CC} ${CC} ${AM_CPPFLAGS} ${AM_DEPFLAGS} ${AM_CFLAGS} -D_INIT=lib$*_init -DPIC -fPIC ${CFLAGS} -o $@ -c $<;
+lib%.la: lib%.lo
+	${AM_VERBOSE_CCLD} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=link ${CCLD} ${AM_LDFLAGS} -module ${LDFLAGS} -o $@ $< -L../libxtables -lxtables ${$*_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 $<;
 
 libxt_NOTRACK.so: libxt_CT.so
 	ln -fs $< $@
@@ -101,7 +105,7 @@ libxt_state.so: libxt_conntrack.so
 	ln -fs $< $@
 
 # Need the LIBADDs in iptables/Makefile.am too for libxtables_la_LIBADD
-ip6t_NETMAP_LIBADD  = -lip6tc
+ip6t_NETMAP_LIBADD  = ../libiptc/libip6tc.la
 xt_RATEEST_LIBADD   = -lm
 xt_statistic_LIBADD = -lm
 
-- 
1.7.10.4

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 979 bytes --]

On Monday 31 December 2012 00:54:06 Jan Engelhardt wrote:
> Like this? We cannot really get rid of mentioning .libs without involving
> libltdl, and there I really do not want to go.

why ?  are the modules run directly out of the build tree, or you just need to 
install them ?  `libtool --mode=install` can install an .la file ...

> +	${AM_VERBOSE_NULL} ln -fs .libs/$@ $@;

i'm not sure why a lot of these rules have trailing semi-colons.  they're 
pointless.

> +	${AM_VERBOSE_CCLD} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=link
> ${CCLD} ${AM_LDFLAGS} -module ${LDFLAGS} -o $@ $< -L../libxtables
> -lxtables ${$*_LIBADD} -rpath ${xtlibdir};

should be ../libxtables/libxtables.la rather than -L/-l for libxtables

>  libxt_NOTRACK.so: libxt_CT.so
>  	ln -fs $< $@
> libxt_state.so: libxt_conntrack.so
>  	ln -fs $< $@

these two rules could use your new $AM_VERBOSE_NULL

otherwise, this is an improvement imo over the existing code
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

On Wednesday 2013-01-02 05:03, Mike Frysinger wrote:

>On Monday 31 December 2012 00:54:06 Jan Engelhardt wrote:
>> Like this? We cannot really get rid of mentioning .libs without involving
>> libltdl, and there I really do not want to go.
>
>why ?  are the modules run directly out of the build tree,

Yes, one can run them out of the build tree; by using
./configure --with-xtlibdir=$PWD/extensions

>> +	${AM_VERBOSE_NULL} ln -fs .libs/$@ $@;
>
>i'm not sure why a lot of these rules have trailing semi-colons.  they're 
>pointless.

Hm must be a habit of doing other programming languages.

>> +	${AM_VERBOSE_CCLD} ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=link
>> ${CCLD} ${AM_LDFLAGS} -module ${LDFLAGS} -o $@ $< -L../libxtables
>> -lxtables ${$*_LIBADD} -rpath ${xtlibdir};
>
>should be ../libxtables/libxtables.la rather than -L/-l for libxtables
>
>>  libxt_NOTRACK.so: libxt_CT.so
>>  	ln -fs $< $@
>> libxt_state.so: libxt_conntrack.so
>>  	ln -fs $< $@
>
>these two rules could use your new $AM_VERBOSE_NULL
>
>otherwise, this is an improvement imo over the existing code
>-mike
>

[PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

Link stage of libip6t_NETMAP failed since recently.

  CCLD     libip6t_NETMAP.so
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld:
cannot find -lip6tc

libip6t_NETMAP.c uses the "ipv6_prefix_length" function from
libip6tc.so; "-lip6tc" is used in the Makefile, but, the directory to
it is not specified.

Why does the link succeed for some people? Because
/usr/lib(64)/libip6tc.so satisfies -lip6tc, but not all environments,
especially those without iptables development files, have that file,
hence this link error can happen.

By suggestion of Mike Frysinger, this patch uses libtool to produce
and link the plugins.

Signed-off-by: Jan Engelhardt <jengelh@inai.de>
---

 * use of ../libxtables/libxtables.la

 extensions/GNUmakefile.in |   20 ++++++++++++--------
 1 file changed, 12 insertions(+), 8 deletions(-)

diff --git a/extensions/GNUmakefile.in b/extensions/GNUmakefile.in
index e71e3ff..adad4d6 100644
--- a/extensions/GNUmakefile.in
+++ b/extensions/GNUmakefile.in
@@ -33,6 +33,7 @@ AM_VERBOSE_CXX    = @echo "  CXX     " $@;
 AM_VERBOSE_CXXLD  = @echo "  CXXLD   " $@;
 AM_VERBOSE_AR     = @echo "  AR      " $@;
 AM_VERBOSE_GEN    = @echo "  GEN     " $@;
+AM_VERBOSE_NULL   = @
 endif
 
 #
@@ -75,7 +76,7 @@ install: ${targets_install}
 	if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi;
 
 clean:
-	rm -f *.o *.oo *.so *.a {matches,targets}.man initext.c initext4.c initext6.c;
+	rm -f *.la *.o *.lo *.so *.a {matches,targets}.man initext.c initext4.c initext6.c;
 	rm -f .*.d .*.dd;
 
 distclean: clean
@@ -89,19 +90,22 @@ init%.o: init%.c
 #
 #	Shared libraries
 #
-lib%.so: lib%.oo
-	${AM_VERBOSE_CCLD} ${CCLD} ${AM_LDFLAGS} -shared ${LDFLAGS} -o $@ $< -L../libxtables/.libs -lxtables ${$*_LIBADD};
+lib%.so: lib%.la
+	${AM_VERBOSE_NULL} ln -fs .libs/$@ $@
 
-lib%.oo: ${srcdir}/lib%.c
-	${AM_VERBOSE_CC} ${CC} ${AM_CPPFLAGS} ${AM_DEPFLAGS} ${AM_CFLAGS} -D_INIT=lib$*_init -DPIC -fPIC ${CFLAGS} -o $@ -c $<;
+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}
+
+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 $<
 
 libxt_NOTRACK.so: libxt_CT.so
-	ln -fs $< $@
+	${AM_VERBOSE_GEN} ln -fs $< $@
 libxt_state.so: libxt_conntrack.so
-	ln -fs $< $@
+	${AM_VERBOSE_GEN} ln -fs $< $@
 
 # Need the LIBADDs in iptables/Makefile.am too for libxtables_la_LIBADD
-ip6t_NETMAP_LIBADD  = -lip6tc
+ip6t_NETMAP_LIBADD  = ../libiptc/libip6tc.la
 xt_RATEEST_LIBADD   = -lm
 xt_statistic_LIBADD = -lm
 
-- 
1.7.10.4

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 51 bytes --]

Acked-by: Mike Frysinger <vapier@gentoo.org>
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Pablo Neira Ayuso]

On Wed, Jan 02, 2013 at 12:23:08PM -0500, Mike Frysinger wrote:
> Acked-by: Mike Frysinger <vapier@gentoo.org>

Applied, thanks for your feedback Mike.

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1507 bytes --]

Hi,

On Wed, Jan 02, 2013 at 09:47:51AM +0100, Jan Engelhardt wrote:
[...]
> --- a/extensions/GNUmakefile.in
> +++ b/extensions/GNUmakefile.in
[...]
> @@ -75,7 +76,7 @@ install: ${targets_install}
>  	if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi;

No, this is a regression.  If ${targets_install} shared objects are made
by libtool, they are intermediate files not expected to be installed by
hand (due to funny RPATHs and so on), so they have to be installed by
libtool --mode=install.

Something like
	for f in $^; do ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=install ${INSTALL} -pm0755 $${f/.so/.la} "${DESTDIR}${xtlibdir}/"; done
would work.

[...]
> @@ -89,19 +90,22 @@ init%.o: init%.c
>  #
>  #	Shared libraries
>  #
> -lib%.so: lib%.oo
> -	${AM_VERBOSE_CCLD} ${CCLD} ${AM_LDFLAGS} -shared ${LDFLAGS} -o $@ $< -L../libxtables/.libs -lxtables ${$*_LIBADD};
> +lib%.so: lib%.la
> +	${AM_VERBOSE_NULL} ln -fs .libs/$@ $@
>  
> -lib%.oo: ${srcdir}/lib%.c
> -	${AM_VERBOSE_CC} ${CC} ${AM_CPPFLAGS} ${AM_DEPFLAGS} ${AM_CFLAGS} -D_INIT=lib$*_init -DPIC -fPIC ${CFLAGS} -o $@ -c $<;
> +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}

Please also add -avoid-version along with -module, otherwise it produces
(and --mode=install installs) useless symlinks.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1245 bytes --]

On Sat, Jan 12, 2013 at 03:34:30AM +0400, Dmitry V. Levin wrote:
> Hi,
> 
> On Wed, Jan 02, 2013 at 09:47:51AM +0100, Jan Engelhardt wrote:
> [...]
> > --- a/extensions/GNUmakefile.in
> > +++ b/extensions/GNUmakefile.in
> [...]
> > @@ -75,7 +76,7 @@ install: ${targets_install}
> >  	if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi;
> 
> No, this is a regression.  If ${targets_install} shared objects are made
> by libtool, they are intermediate files not expected to be installed by
> hand (due to funny RPATHs and so on), so they have to be installed by
> libtool --mode=install.
> 
> Something like
> 	for f in $^; do ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=install ${INSTALL} -pm0755 $${f/.so/.la} "${DESTDIR}${xtlibdir}/"; done
> would work.

No, it didn't work because of ${pfx_symlinks} modules which are not
libtool files.  I've managed to build it with a more complex yet reliable
rule:

	for f in $^; do la="$${f/.so/.la}"; if test -f "$$la"; then ../libtool ${AM_LIBTOOL_SILENT} --tag=CC --mode=install ${INSTALL} -pm0755 "$$la" "${DESTDIR}${xtlibdir}/"; elif test -L "$$f"; then cp -a "$$f" "${DESTDIR}${xtlibdir}/"; else exit 1; fi || exit; done


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] build: resolve link failure for ip6t_NETMAP

[Jan Engelhardt]

On Saturday 2013-01-12 00:34, Dmitry V. Levin wrote:
>On Wed, Jan 02, 2013 at 09:47:51AM +0100, Jan Engelhardt wrote:
>[...]
>> --- a/extensions/GNUmakefile.in
>> +++ b/extensions/GNUmakefile.in
>[...]
>> @@ -75,7 +76,7 @@ install: ${targets_install}
>>  	if test -n "${targets_install}"; then install -pm0755 $^ "${DESTDIR}${xtlibdir}/"; fi;
>
>No, this is a regression.  If ${targets_install} shared objects are made
>by libtool, they are intermediate files not expected to be installed by
>Please also add -avoid-version along with -module, otherwise it produces
>(and --mode=install installs) useless symlinks.

Already posted patches for those -
http://marc.info/?l=netfilter-devel&m=135783093113355&w=2