Hi,
currently it is not possible to build Bro on RedHat / CentOs 6 or earlier
because the cmake version available on those systems is too low.
Is there any important reason why we need 2.8? CentOs 6 only has 2.6.4 by
default.
Johanna
It looks like RH/CentOS 6.6 has cmake 2.8.12, and RH/CentOS 6.5
and earlier have cmake 2.6.4.
currently it is not possible to build Bro on RedHat / CentOs 6 or earlier
because the cmake version available on those systems is too low.
I think 6.6 has CMake 2.8.12.2 now.
But yeah, before they were at 2.6.4.
Is there any important reason why we need 2.8?
Not especially important, but newer versions of CMake were emitting some CMake policy warnings at bro-aux configure-time that I didn’t see a way to fix without using generator expressions, which became available in CMake 2.8.
If you can’t upgrade to 6.6, is it at least an option for you to compile a newer CMake from source?
- Jon
> currently it is not possible to build Bro on RedHat / CentOs 6 or earlier
> because the cmake version available on those systems is too low.I think 6.6 has CMake 2.8.12.2 now.
But yeah, before they were at 2.6.4.
Ah, ok. I am trying to build a bro version using the opensuse build
service - and they apparently use only the old packages of those
distributions when you create your packages.
> Is there any important reason why we need 2.8?
Not especially important, but newer versions of CMake were emitting some
CMake policy warnings at bro-aux configure-time that I didn’t see a way
to fix without using generator expressions, which became available in
CMake 2.8.If you can’t upgrade to 6.6, is it at least an option for you to compile a newer CMake from source?
I will try, it actually might be possible to make it a compile-time-only
requirement.
Just to check - is removing the dependency for 2.8 as easy as changing the
minimal cmake version and removing a few lines from one of the cmake
scripts? Because in that case I would be tempted to just automatically
patch it out when building for those distributions (I have a few
distribution specific actions in the build files in any case).
Johanna
Yeah, patching it out should be easy for the moment.
Here’s the relevant change from the bro repo:
https://github.com/bro/bro/commit/d8890ea009fdb94ecffcf826bbfd23577396365e
And the one from bro-aux:
https://github.com/bro/bro-aux/commit/0b713c027d3efaaca50e5df995c02656175573cd
I think that one place in bro-aux is the only place that’s using CMake 2.8 features right now, but let me know if you find otherwise and need any help.
- Jon
[...]
Thank you, that worked. One more question - currently Bro does not compile
on systems that use libpcap < 1.1.1, because PCAP_NETMASK_UNKNOWN is not
defined (example compile error:
https://build.opensuse.org/package/live_build_log/home:0xxon:bro/bro-nightly/xUbuntu_10.04/i586)
Could we perhaps test for the definition of that macro and either define
it to something ourselves in that case, or just use another code-path? On
a first glance, it does not look especially critical that we use it, but I
am not really familiar with that case.
Johanna
I’m not that familiar either, but think it may be fine to provide our own preprocessor definition if it doesn’t exist. Robin, what do you think? Was there any other functionality of recent libpcaps that’s used now? Do we know what minimum version of libpcap should be required and checked at configure time?
- Jon
I'll remove the dependency on the macro, it's used mainly as
placeholder value, and we can use our own for that.
Robin
Thank you. However it looks like we actually require more parts of the
newer libpcap version - now the build fails because of
pcap_offline_filter:
https://build.opensuse.org/package/live_build_log/home:0xxon:bro/bro-nightly/RedHat_RHEL-5/i586
Johanna
Oh, I thought that's a function which had been around for a while.
That's not easy to get rid of, it provides BPF filtering for packet
source plugins that can't do that natively (like netmap). Do you
happen to know if there's another way to do that with older pcaps?
Robin
> newer libpcap version - now the build fails because of
> pcap_offline_filter:Oh, I thought that's a function which had been around for a while.
That's not easy to get rid of, it provides BPF filtering for packet
source plugins that can't do that natively (like netmap). Do you
happen to know if there's another way to do that with older pcaps?
No, I don't. But that is fine I guess - in that case we just do not have
packages for RH5 anymore. Your fix made it compile on a few other
distributions (like older ubuntus), so it was not in vain 
Johanna