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
