Summary: | net-firewall/iptables-1.4.8-r1: libiptc is missing NEEDED entries when built with as-needed | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andreas K. Hüttel <dilfridge> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bugs, dilfridge, gentoo, leio |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://bugzilla.netfilter.org/show_bug.cgi?id=674 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 375733 |
Description
Andreas K. Hüttel
2010-08-25 21:21:47 UTC
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. |