I am taking care of a package in sunrise that uses libiptc. Recently I noticed that the build fails; configure claims that it cannot find a working libiptc. Some digging brought the following information: * The autoconf test is "AC_CHECK_LIB(iptc, iptc_init, ..." * Only when iptables is built with --as-needed, this fails. scanelf on usr/lib64/libiptc.so.0.0.0 reports * when built with as-needed: ET_DYN libc.so.6 /usr/lib64/libiptc.so.0.0.0 * when built without as-needed: ET_DYN libip4tc.so.0,libip6tc.so.0,libc.so.6 /usr/lib64/libiptc.so.0.0.0 This is not a problem per se, since there are no unresolved symbols in libiptc. However, programs may expect the symbol iptc_init to be present when linking -liptc. And that symbol is actually defined in libip4tc...
dont assign packages directly. let bug-wranglers do it.
probably fixed now http://sources.gentoo.org/net-firewall/iptables/iptables-1.4.9.1-r2.ebuild?r1=1.2&r2=1.3
I think this bug might require reopening. The latest iptables is 1.4.12.1-r1 as I am typing this, and it is build *with* --as-needed, which causes /lib/libiptc.so.0 to *not* be linked against libip4tc and libip6tc. I tried adding the fix mentioned in comment #2 but that didn't help. However, building with LDFLAGS="-Wl,--no-as-needed" solves the problem. I am not well-versed enough in ebuild lingo to turn this into a usable patch though.
Obviously that should have read "The latest iptables is 1.4.12.1-r2 as I am typing this". Sorry about the noise.
Or maybe not. Very, very sorry :-/
Reopening as per comment 3 and following... even though they slightly confuse me :]
(In reply to comment #6) > Reopening as per comment 3 and following... even though they slightly > confuse me :] Can't blame you :-/ Apologies again! I dug a little deeper and found that --no-as-needed can be made specific to the sub-libs we are interested in. One sure fact is that the vanilla sources do not display the problem, so I am quite positive that elibtoolize is responsible for this --as-needed flag being applied globally and for the resulting linking problems.
I guess one interesting question is why --as-needed removes it as well (at least for me).
(In reply to comment #8) > I guess one interesting question is why --as-needed removes it as well (at > least for me). …as already outlined by Mike in the upstream ticket in URL.
I am by no means an expert in linking issues so I gathered some data and external help on this issue. What I do know for sure is that iptables' Makefile for libiptc allows $LDFLAGS to override its $libiptc_la_LDFLAGS. As a result, libiptc is linked with -Wl,--no-as-needed AND -Wl,--as-needed, in this order. I don't think --no-as-needed can be re-introduced in a way similar to the patch from comment #2. Also, I tried various methods involving flag-o-matic filter-ldflags and append-ldflags, to no avail. Letting $LDFLAGS be overriden by $libiptc_la_LDFLAGS is a sure fix, but I am told it goes against the way things are normally done. I'll let you be the judges of that.
the code has changed significantly. please file a new bug for the new version with full build log/etc...
(In reply to comment #11) > the code has changed significantly. please file a new bug for the new > version with full build log/etc... Latest version (1.4.13) fixed the problem for me.
