On Sat, Oct 26, 2019 at 06:40:00PM +1100, Duncan Roe wrote: > On Wed, Oct 23, 2019 at 10:48:36PM +0200, Pablo Neira Ayuso wrote: > > On Thu, Oct 24, 2019 at 02:31:42AM +1100, Duncan Roe wrote: > > > BTW, ldd of my app shows libnfnetlink.so although it doesn't use any deprecated > > > functions. Is that expected? > > > > Yes, there is still code in the libraries that refer to libnfnetlink. > > Replacing some of that code should be feasible via libmnl, it is a > > task that has been in my TODO list for long time. There's always > > something with more priority in the queue. > > Using *nm -D* (dynamic symbols) I see > - libmnl.so: no U (undefined) symbols satisfied by libnfnetlink.so > - nfq (my app): no U symbols satisfied by libnfnetlink.so > - libnetfilter_queue.so: many U symbols satisfied by libnfnetlink.so > Only way to tell whether the libnfnetlink.so references in libnetfilter_queue.so > are confined to the deprecated functions would be to do a build without them. > If that eliminates libnfnetlink references, then maybe we could think about a > configure option to not build them (also excluding them from the doco). Apparently, there are many people using this old libnetfilter_queue API, we cannot get rid of it. We could though explore using libmnl instead of libnfnetlink from the old libnetfilter_queue API implementation. > But that's for another day - I'll get back to libnetfilter_queue doco for now. Agreed.
