I'll take a look at it. .Seth
On 15 Jul 2019, at 12:32, Michael Dopheide wrote: > 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 <jus...@corelight.com> > 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 >> <jan.grashoe...@gmail.com> >> 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 <jsi...@corelight.com> >>>>> wrote: >>>>> >>>>> >>>>> >>>>>> On Fri, Jul 12, 2019 at 3:46 PM Michael Dopheide >>>>>> <dophe...@es.net> >>> 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 >>>>> zeek-dev@zeek.org >>>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >>>> >>>> >>>> _______________________________________________ >>>> zeek-dev mailing list >>>> zeek-dev@zeek.org >>>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >>>> >>> _______________________________________________ >>> zeek-dev mailing list >>> zeek-dev@zeek.org >>> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >>> >> >> >> -- >> Justin >> _______________________________________________ >> zeek-dev mailing list >> zeek-dev@zeek.org >> http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev >> > _______________________________________________ > zeek-dev mailing list > zeek-dev@zeek.org > http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev -- Seth Hall * Corelight, Inc * www.corelight.com _______________________________________________ zeek-dev mailing list zeek-dev@zeek.org http://mailman.icsi.berkeley.edu/mailman/listinfo/zeek-dev