Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 255086 - net-analyzer/ipac-ng-1.31-r2 doesn't work with net-firewall/iptables-1.4.0-r1: no libipt_standard.so
Summary: net-analyzer/ipac-ng-1.31-r2 doesn't work with net-firewall/iptables-1.4.0-r1...
Status: RESOLVED WONTFIX
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: High normal with 1 vote (vote)
Assignee: Gentoo Netmon project
URL:
Whiteboard:
Keywords:
Depends on: 319085
Blocks:
  Show dependency tree
 
Reported: 2009-01-15 19:18 UTC by Jan Kundrát (RETIRED)
Modified: 2011-05-24 14:11 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Kundrát (RETIRED) gentoo-dev 2009-01-15 19:18:34 UTC
velbloud ~ # fetchipac -S
Couldn't load target `standard':/lib/iptables/libipt_standard.so: cannot open shared object file: No such file or directory

Indeed, there's no such file (while there was one with net-firewall/iptables-1.3.8-r3).

Looking at the source code, it seems that it wants to load some kind of a "generic" module from iptables, and fails in that attempt...
Comment 1 Kevin 2009-03-18 04:41:11 UTC
Well if there isn't a way to get iptables to build that .SO, there might not be a fix available that doesn't involve updating ipac-ng. AFAIK ipac-ng isn't being maintained anymore and so someone would have to take over and write a new version. I'm sure it would be welcomed though since this error started showing up on their mailing list a couple years ago.
Comment 2 heady 2009-05-24 23:19:35 UTC
This bug and bug #191582 are as far as I can tell are the same symptom.

Take this with a grain of salt as I'm new at this.

ipac-ng seems to try to preload iptables modules prior to setting up the chains and rules.

However, it appears that ipac-ng has been enhanced once or twice so in some cases it pulls the lib directory from the configure macros; whereas, in some places it has hard-coded filenames and paths.

Iptables has moved some of the shared .so files to /lib/xtables or /lib64/xtables and have changed the prefix from libipt_%s.so to libxt_%s.so.  Therefore, ipac-ng unmodified cannot find the shared .so files.

I initially thought it would be a simple task of hunting through and updating the configure paths and changing the hard-coded filenames and paths.  However, when I've done that I get:
./fetchipac -S
Couldn't load target `standard':/lib64/xtables/libxt_standard.so: undefined symbol: xtables_register_target

Now this is a bit of a guess...

But in iptables.c it seems that they have taken complete chucks of code from iptables-1.2.2 and use their own *.h files.  Therefore, in >iptables-1.3.8 like my iptables-1.4.2 the code chunks are different and I therefore get, the undefined symbols error from above.

I'm at a bit of a loss of what to try next - I might have a look at what some of the other distributions have done.  Or I might try to copy the code blocks over from iptables-1.4.2.
Comment 3 Peter Volkov (RETIRED) gentoo-dev 2011-05-24 14:11:51 UTC
Package was dropped from the tree.