>From: [email protected] >[mailto:[email protected]] On Behalf Of Luca Deri >Sent: den 24 februari 2014 08:57 >To: [email protected] >Subject: Re: [Ntop-misc] Issue with Suricata and other 3rd party compilations >against PF_RING svn > >Hi all, >ibnuma is necessary as PF_RING was compiled with it: so either you deinstall >the library prior to compile PF_RING or you add it to your PF_RING-based apps. >We use such library as we need to properly allocate memory/balance apps across >cores< > >Luca
Hi! Actually, I had to install libnuma-dev to get PF_RING to compile at all. I might have been blind, but I didn't find a "--without-numa" switch or similar in the configure script. My point is (based on input from the oisf-devel list, and this page https://wiki.debian.org/ToolChain/DSOLinking ), that there might be a better way to link with the numa libs, so this issue doesn't occur when compiling 3rd party apps against PF_RING. I guess the same situation applies to the rt lib dependency. Again, I'm not familiar with this level of programming, but just wanted to share my thoughts :) If you follow the thread in the oisf-devel link I posted earlier, the devs there had some suggestions. I'll just pass along a quote from there: "In this case, this is a bug in pf_ring who should link with the numa libs and require the devel harder to be installed at compile time. So please ask for a fix to of pf_ring team." And if that turns out to not be possible, I think it would be prudent to update relevant guides with LIBS="-lrt lnuma" when running ./configure >On 02/24/2014 08:24 AM, Joan wrote: >Same thing happened with pmacct, the solutions was to add librt and libnuma as >depens for the pfring on compile time, it's a change that appears in 5.6.2 and >it was not present in 5.6.1 that compiles without linking with those libs. >After doing the changes everything works as expected. Yup, sort of just like I wrote :) >>2014-02-23 22:54 GMT+01:00 Johan Karlsson <[email protected]>: >>Hi! >> >>I apologize if this has been brought up already, haven't had time to read up >>on the latest threads. >> >>While building Suricata against the latest PF_RING svn i noticed that >>./configure failed due to undefined references to numa functions. I'm >>guessing this will be seen in other 3rd party apps being built against >>PF_RING svn as well. >> >>I use Debian Wheezy and I believe it's related to the "recent" DSO Linking >>changes. I think this applies to later Ubuntu editions too. While I do know >>some programming, I'm not a programmer by profession or so, so I can't >>suggest the proper action here. But I think this link below might give you >>some hints to maybe change how linking against numa is done: >> >>https://wiki.debian.org/ToolChain/DSOLinking >> >>I've brought this up on the OISF-devel mailing list too: >>https://lists.openinfosecfoundation.org/pipermail/oisf-devel/2014-February/002970.html >> >>At the moment, the solutions is to pass -lnuma via LIBS when running >>./configure >> >>Maybe the PF_RING Suricata guide (and other guides for 3rd party >>applications) can be changed to reflect this. At least those utilizing the >>PF_RING svn. >> >>The following section at >>http://www.ntop.org/pf_ring/accelerating-suricata-with-pf_ring-dna/ >>--- >>Compile and install >> >> ./autogen.sh && LIBS=-lrt ./configure --enable-pfring ... >>--- >> >>Should be changed to: >> >>--- >>Compile and install >> >> ./autogen.sh && LIBS="-lrt -lnuma" ./configure --enable-pfring ... >>--- >> >>Regards, >> >>Johan Karlsson >>_______________________________________________ >>Ntop-misc mailing list >>[email protected] >>http://listgateway.unipi.it/mailman/listinfo/ntop-misc Regards, Johan Karlsson _______________________________________________ Ntop-misc mailing list [email protected] http://listgateway.unipi.it/mailman/listinfo/ntop-misc
