Updating myricom to build against the install tree looks like it's going to work and will be much cleaner.
-Dop On Mon, Jul 15, 2019 at 9:46 AM Justin Azoff <[email protected]> wrote: > Speaking of that, you made this commit: > > > https://github.com/J-Gras/bro-af_packet-plugin/commit/5a5d8bb74f162841111b26880137f51683e60ac1 > > which has the new changes(from the skeleton?) that allows it to be built > without the full source tree, but the myricom package is still using the > old cmake bits. > > On Mon, Jul 15, 2019 at 9:57 AM Jan Grashöfer <[email protected]> > wrote: > >> So https://github.com/J-Gras/bro-af_packet-plugin/issues/11 isn't an >> issue anymore due to backwards compatible symlinks? >> >> On 13/07/2019 03:22, Michał Purzyński wrote: >> > We just migrated to master with the name change and the afpacket >> plugin, so I know the Zeek code is OK. >> > >> > >> >> On Jul 12, 2019, at 5:52 PM, Jon Siwek <[email protected]> wrote: >> >> >> >> >> >> >> >>> On Fri, Jul 12, 2019 at 3:46 PM Michael Dopheide <[email protected]> >> wrote: >> >>> Background: We like to run 'master', but with the name change it >> broke too many things and we had to stick to 2.6.2 for the time being. >> Since then, I've started trying to convert our ansible scripts and prepare >> to make the jump. Today I discovered the bro-myricom package would fail to >> build. >> >>> >> >>> Has anyone attempted this yet? I can get it to build with a couple >> minor changes: >> >>> >> >>> src/Myricom.cc >> >>> @@ -1,4 +1,4 @@ >> >>> #include "bro-config.h" >> >>> #include "zeek-config.h" >> >>> >> >> >> >> Can you give more info on how to reproduce this one? The master >> branch should currently be installing "zeek-config.h" along with a symlink >> to it named "bro-config.h", with the ideal being that people wouldn't have >> to make this change. >> >> >> >> IIRC, since we changed our default install prefix from /usr/local/bro >> to /usr/local/zeek, there's also a bit different logic if we find someone >> is going to install over an old Bro installation that was still at the old >> prefix, so might be good to know if you're installing fresh or upgrading >> from the old version. >> >> >> >> >> >>> tests/Scripts/get-bro-env >> >>> @@ -8,7 +8,7 @@ bro=`cat ${base}/../../build/CMakeCache.txt | grep >> BRO_DIST | cut -d = -f 2` >> >>> if [ "$1" = "brobase" ]; then >> >>> echo ${bro} >> >>> elif [ "$1" = "bropath" ]; then >> >>> ${bro}/build/bro-path-dev >> >>> ${bro}/build/zeek-path-dev >> >>> >> >> >> >> This one just looks like an oversight on our end, we'll need to keep >> creating (or symlinking) that "build/bro-path-dev" file. >> >> >> >>> >> >>> Unfortunately, we end up with another problem: >> >>> zeek -N >> >>> internal error in /home/zeek/zeek-myricom/build/scripts/./init.bro, >> line 37: bad reference count [0] >> >>> >> >>> Line 37 is just SNF_RSS_IP: >> >>> const snf_rss_mode: set[RssField] = { >> >>> SNF_RSS_IP, >> >>> SNF_RSS_SRC_PORT, >> >>> SNF_RSS_DST_PORT >> >>> } &redef; >> >> >> >> This doesn't look related to the Bro-Zeek renaming, but possibly some >> enum optimizations we did that are being tickled by what this plugin is >> doing. Particularly there's an enum being declared/defined twice: >> >> >> >> >> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/src/myricom.bif#L9-L15 >> >> >> >> and >> >> >> >> >> https://github.com/sethhall/bro-myricom/blob/89815d89e0ba6957149521cf99e608c0dc909f6d/scripts/init.bro#L26-L32 >> >> >> >> Possibly old versions of Bro were fine with that happening, but not >> anymore. Generally seems odd that we don't explicitly give an error >> message to indicate the same enum being defined in two separate places. >> >> >> >> I'll look more into what the proper fix is next week, but if you're >> just looking to try to get something working in the meantime, a workaround >> may be to comment out or remove the entire RssField enum definition inside >> the init.bro script. >> >> >> >>> Clearly I'm not gonna get lucky with an easy fix. Doing a simple >> search/replace for bro/zeek across the whole tree doesn't seem viable as >> things like bro-bif.h haven't changed names. Has anyone started digging >> into how plugin packages will need to be updated? >> >> >> >> Generally the idea is to be mostly backward compatible so people >> aren't forced to make any changes to external plugins, but looks like >> there's a couple small things we overlooked or had not tested that we'll >> want to fix before the 3.0 release, so thanks for the early feedback. >> >> >> >> - Jon >> >> _______________________________________________ >> >> zeek-dev mailing list >> >> [email protected] >> >> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >> > >> > >> > _______________________________________________ >> > zeek-dev mailing list >> > [email protected] >> > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >> > >> _______________________________________________ >> zeek-dev mailing list >> [email protected] >> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >> > > > -- > Justin > _______________________________________________ > zeek-dev mailing list > [email protected] > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >
_______________________________________________ zeek-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev
