On Wednesday 2009-01-21 19:39, jamal wrote: > >I agree. And I have a patch which resolves the current issue with >some preliminary testing from Yawhen Kasarzhewski <y...@pisem.net> >I still need to proof-read it and probably break it into three separate >patches before submission. > >I am afraid I cant get rid of iptables as is from ipt - it is needed >for older kernels.
Well that is bad. But it is not really my problem. m_ipt has so horribly abused iptables it is quite unfixable IMHO. >So Instead I compile something else once i detect >there is xtables in the system, I compile with xtables support. If that works, ok. But I doubt it would get accepted upstream. >See attached. In the next iteration I will like to remove everything >tagged with "XXX: TC_CONFIG_XIPT_H" by making sure everything i need IPT -> XT. (not IPXT) >> Here, this is what I think should be the first patch (see below). >> This already turns up some further issues that need to be >> resolved first, among: >> >> - the XTABLES_LIBDIR define must be changeable at ./configure time >> >> - it would make sense to rename most of the iptables functions >> to have a prefix (i'll prepare that) >> >> - making most of the functions inside m_ipt.c static so they do >> not cause a dynamic linker overlap (e.g. xtables_register_target >> which is as of yet still replicated) >> >> What do you think? > >Does it compile? Mostly. I cannot get iproute2 compiled because it cannot find the definitions for struct tcmsg, but I think I got rid of all the iptables-related compile errors. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
