# Bro 2.6 beta feedback? **URL:** \ **Category:** Zeek\ **Created:** [October 2, 2018, 1:37pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482 "2018-10-02T13:37:23Z")\ **Posts on this page:** 14\ **Page:** 1
**Author:** ![seth](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/seth/32/642_2.png) [@seth](https://community.zeek.org/u/seth)\ **Post date:** [October 2, 2018, 1:37pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/1 "2018-10-02T13:37:23Z")
I've seen very little feedback from the Bro 2.6 beta that was posted recently. I'm wondering how many people have tried it and if there is any feedback about it? Thanks!    .Seth ---
**Author:** ![Michael\_Shirk](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@Michael\_Shirk](https://community.zeek.org/u/Michael_Shirk)\ **Post date:** [October 2, 2018, 2:06pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/2 "2018-10-02T14:06:02Z")
I can report bro "version 2.6-beta2-3" built and started on 9/21/2018 on FreeBSD 11.2-RELEASE-p2 is still working...no issues for me (no plugins/packages) ---
**Author:** ![dopheide](https://avatars.discourse-cdn.com/v4/letter/d/74df32/32.png) [@dopheide](https://community.zeek.org/u/dopheide)\ **Post date:** [October 2, 2018, 2:58pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/3 "2018-10-02T14:58:43Z")
Adding to the data points and hopefully confidence of people who may be waiting… ESnet is running dev/2.7 (which includes all of the 2.6 changes) in production with no issues. CentOS 7 and MyricomSNF. -Dop ---
**Author:** ![David\_Hoelzer](https://avatars.discourse-cdn.com/v4/letter/d/2acd7d/32.png) [@David\_Hoelzer](https://community.zeek.org/u/David_Hoelzer)\ **Post date:** [October 2, 2018, 8:06pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/4 "2018-10-02T20:06:20Z")
Working great for us. We've had to rewrite some scripts and such, but otherwise, no issues. \_\_ Thanks for your good (hard) work! ---
**Author:** ![seth](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/seth/32/642_2.png) [@seth](https://community.zeek.org/u/seth)\ **Post date:** [October 2, 2018, 8:38pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/5 "2018-10-02T20:38:53Z")
> Working great for us. We've had to rewrite some scripts and such, but otherwise, no issues. \_\_ Any comments about what scripts you had to rewrite or the reasons for why they needed rewritten? > Thanks for your good (hard) work! I can't take much credit for this release. I had remarkably little code it, but I think it's a pretty nice release! A ton of work over multiple years has gone into it.   .Seth ---
**Author:** ![Aashish\_Sharma1](https://avatars.discourse-cdn.com/v4/letter/a/a88e57/32.png) [@Aashish\_Sharma1](https://community.zeek.org/u/Aashish_Sharma1)\ **Post date:** [October 2, 2018, 10:03pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/6 "2018-10-02T22:03:17Z")
So, I tried running this on FreeBSD 10.3-STABLE and I see the following, builds fine but when trying to run: $ ./broctl install Error: running "bro -v" failed with output: Undefined symbol "\_ZN6broker5topic8reservedE" referenced from COPY relocation in /home/bro/master/bin/bro I do see that bro builds against its own libcaf: $ ldd ./bro ./bro:         libpcap.so.1 =\> /usr/local/opt/snf/lib/libpcap.so.1 (0x400ef1000)         libssl.so.9 =\> /usr/local/lib/libssl.so.9 (0x40113a000)         libcrypto.so.9 =\> /usr/local/lib/libcrypto.so.9 (0x401400000)         libz.so.6 =\> /lib/libz.so.6 (0x401852000)         libbroker.so.0 =\> /usr/local/lib/libbroker.so.0 (0x401c00000)         libcaf\_core.so.0.16.0 =\> /home/bro/master/lib/libcaf\_core.so.0.16.0 (0x402200000)         libcaf\_io.so.0.16.0 =\> /home/bro/master/lib/libcaf\_io.so.0.16.0 (0x402800000)         libcaf\_openssl.so.0.16.0 =\> /home/bro/master/lib/libcaf\_openssl.so.0.16.0 (0x402c86000)         libc++.so.1 =\> /usr/local/lib/libc++.so.1 (0x402ee0000)         libcxxrt.so.1 =\> /lib/libcxxrt.so.1 (0x4031a0000)         libm.so.5 =\> /lib/libm.so.5 (0x4033bd000)         libgcc\_s.so.1 =\> /lib/libgcc\_s.so.1 (0x4035e6000)         libthr.so.3 =\> /lib/libthr.so.3 (0x4037f4000)         libc.so.7 =\> /lib/libc.so.7 (0x403a18000)         libsnf.so.0 =\> /usr/local/opt/snf/lib/libsnf.so.0 (0x403dc6000)         libcaf\_core.so.0.14.1 =\> /usr/local/lib/libcaf\_core.so.0.14.1 (0x403fd6000)         libcaf\_io.so.0.14.1 =\> /usr/local/lib/libcaf\_io.so.0.14.1 (0x4042c4000)         libcxxrt.so =\> /usr/local/lib/libcxxrt.so (0x404574000)         librt.so.1 =\> /usr/lib/librt.so.1 (0x404790000) Aashish ---
**Author:** ![Azoff\_Justin\_S](https://avatars.discourse-cdn.com/v4/letter/a/dec6dc/32.png) [@Azoff\_Justin\_S](https://community.zeek.org/u/Azoff_Justin_S)\ **Post date:** [October 2, 2018, 10:08pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/7 "2018-10-02T22:08:51Z")
>        libcaf\_core.so.0.16.0 =\> /home/bro/master/lib/libcaf\_core.so.0.16.0 (0x402200000) >        libcaf\_io.so.0.16.0 =\> /home/bro/master/lib/libcaf\_io.so.0.16.0 (0x402800000) .. >        libcaf\_core.so.0.14.1 =\> /usr/local/lib/libcaf\_core.so.0.14.1 (0x403fd6000) >        libcaf\_io.so.0.14.1 =\> /usr/local/lib/libcaf\_io.so.0.14.1 (0x4042c4000) Looks like you have an older version of caf installed in /usr/local that may be conflicting with things. I helped someone on IRC with a similar problem and removing any old caf libraries and header files in /usr/local fixed things. ---
**Author:** ![Michael\_Shirk](https://avatars.discourse-cdn.com/v4/letter/m/aeb1de/32.png) [@Michael\_Shirk](https://community.zeek.org/u/Michael_Shirk)\ **Post date:** [October 2, 2018, 10:14pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/8 "2018-10-02T22:14:34Z")
I had that issue where I had to remove the OS installed libcaf on FreeBSD. ---
**Author:** ![David\_Hoelzer](https://avatars.discourse-cdn.com/v4/letter/d/2acd7d/32.png) [@David\_Hoelzer](https://community.zeek.org/u/David_Hoelzer)\ **Post date:** [October 2, 2018, 10:31pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/9 "2018-10-02T22:31:24Z")
I'll get back to you on script rewrites.     \> Working great for us. We've had to rewrite some scripts and such, but     \> otherwise, no issues. \_\_          Any comments about what scripts you had to rewrite or the reasons for     why they needed rewritten?          \> Thanks for your good (hard) work!          I can't take much credit for this release. I had remarkably little code     it, but I think it's a pretty nice release! A ton of work over multiple     years has gone into it.            .Seth ---
**Author:** ![seth](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/seth/32/642_2.png) [@seth](https://community.zeek.org/u/seth)\ **Post date:** [October 2, 2018, 11:00pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/10 "2018-10-02T23:00:41Z")
Hm, that makes me wonder if we should do something like set an RPATH to make sure the correct libcaf is used. Jon, does that make sense? It seems that this problem will only come up more frequently as caf is packaged by more systems.   .Seth ---
**Author:** ![johanna](https://avatars.discourse-cdn.com/v4/letter/j/50afbb/32.png) [@johanna](https://community.zeek.org/u/johanna)\ **Post date:** [October 3, 2018, 12:17am UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/11 "2018-10-03T00:17:09Z")
I am not sure that that will help - setting an rpath in packaged binaries is typically at least discouraged. We actually also don’t do it in the packages that we do (or will) ship. For example, see [https://wiki.debian.org/RpathIssue](https://wiki.debian.org/RpathIssue), [https://www.debian.org/doc/manuals/maint-guide/advanced.en.html](https://www.debian.org/doc/manuals/maint-guide/advanced.en.html), [https://fedoraproject.org/wiki/Packaging\_tricks#Acceptable\_use\_of\_rpath](https://fedoraproject.org/wiki/Packaging_tricks#Acceptable_use_of_rpath) (rpmlint raises it as an error; it can be considered ok in fedora for internal libraries), [https://en.opensuse.org/openSUSE:Packaging\_checks](https://en.opensuse.org/openSUSE:Packaging_checks) (this seems to outright prohibit its use). But - perhaps we should recognize such situations and refuse to compile/warn users that they mightt have to re-set their dynamic link paths? Johanna ---
**Author:** ![Jon\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/71c47a/32.png) [@Jon\_Siwek](https://community.zeek.org/u/Jon_Siwek)\ **Post date:** [October 3, 2018, 12:46am UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/12 "2018-10-03T00:46:10Z")
An RPATH is already set by default (regardless of platform): $ readelf -d /usr/local/bro/bin/bro | grep RPATH 0x000000000000000f (RPATH) Library rpath: [/usr/local/bro/lib] $ readelf -d /usr/local/bro/lib/libbroker.so | grep RPATH 0x000000000000000f (RPATH) Library rpath: [/usr/local/bro/lib] $ freebsd-version 10.3-RELEASE-p29 I tried reproducing the problem by faking it out with CAF libs installed in /usr/local: $ ls /usr/local/lib/libcaf\_\* /usr/local/lib/libcaf\_core.so /usr/local/lib/libcaf\_core.so.0.15.3 /usr/local/lib/libcaf\_io.so /usr/local/lib/libcaf\_io.so.0.15.3 But that still works fine for me: $ /usr/bin/ldd /usr/local/bro/bin/bro /usr/local/bro/bin/bro: libpcap.so.8 =\> /lib/libpcap.so.8 (0x80162b000) libssl.so.7 =\> /usr/lib/libssl.so.7 (0x801870000) libcrypto.so.7 =\> /lib/libcrypto.so.7 (0x801adc000) libz.so.6 =\> /lib/libz.so.6 (0x801ed1000) libbroker.so.0 =\> /usr/local/bro/lib/libbroker.so.0 (0x802200000) libthr.so.3 =\> /lib/libthr.so.3 (0x802e71000) libcaf\_core.so.0.16.0 =\> /usr/local/bro/lib/libcaf\_core.so.0.16.0 (0x803200000) libcaf\_io.so.0.16.0 =\> /usr/local/bro/lib/libcaf\_io.so.0.16.0 (0x803c00000) libcaf\_openssl.so.0.16.0 =\> /usr/local/bro/lib/libcaf\_openssl.so.0.16.0 (0x80453e000) libc++.so.1 =\> /usr/lib/libc++.so.1 (0x804844000) libcxxrt.so.1 =\> /lib/libcxxrt.so.1 (0x804b03000) libm.so.5 =\> /lib/libm.so.5 (0x804d20000) libgcc\_s.so.1 =\> /lib/libgcc\_s.so.1 (0x804f49000) libc.so.7 =\> /lib/libc.so.7 (0x805157000) So not sure why Aashish or others had problems with alternate CAF installations. - Jon ---
**Author:** ![Jon\_Siwek](https://avatars.discourse-cdn.com/v4/letter/j/71c47a/32.png) [@Jon\_Siwek](https://community.zeek.org/u/Jon_Siwek)\ **Post date:** [October 3, 2018, 12:52am UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/13 "2018-10-03T00:52:00Z")
For local installs where we only ever intend to load libraries that were a part of the same build, it seems reasonable to have an RPATH. For binary packages, I agree that it's not as good an idea, and that's what the `configure --binary-package` flag was meant to help with: it disables setting of RPATH instead of doing what normally happens in cmake/SetupRPATH.cmake - Jon ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:46pm UTC](https://community.zeek.org/t/bro-2-6-beta-feedback/5482/14 "2022-05-06T15:46:06Z")
Closed on May 6, 2022, 3:46pm UTC