netmap 2.0.0 vs. zeek 4.0.0

I'm trying to update the FreeBSD zeek port for 4.0.0 and am having trouble getting netmap 2.0.0 to build which seems to assume that zeek will be installed in /usr/local when it is built:

     [ 40%] Building CXX object CMakeFiles/Zeek-Netmap.freebsd-amd64.dir/src/Plugin.cc.o
     In file included from /wrkdirs/usr/ports/security/zeek/work/zeek-netmap-2.0.0/src/Plugin.cc:3:
     In file included from /wrkdirs/usr/ports/security/zeek/work/zeek-netmap-2.0.0/src/Plugin.h:6:

/wrkdirs/usr/ports/security/zeek/work/zeek-netmap-2.0.0/src/zeek-compat.h:4:10: fatal error: 'zeek/zeek-config.h' file not found
     #include <zeek/zeek-config.h>
          ^~~~~~~~~~~~~~~~~~~~
     1 error generated.
     *** Error code 1

Due to the way FreeBSD packages are built at this point zeek is installed but in /wrkdirs/usr/ports/security/zeek/work/stage/usr/local, not /usr/local.

With 3.X I was using the configure script in bro-netmap, I started out trying to do something similar:

     post-install-NETMAP-on:
             ${LN} -s ../.build ${WRKSRC}/build
             cd ${WRKSRC_zeek_netmap} && ./configure --zeek-dist=${WRKSRC} \
                 --install-root=${STAGEDIR}${PREFIX}/lib/zeek/plugins
             cd ${WRKSRC_zeek_netmap}/build && make && make install

I tried using env to set CFLAGS and CXXFLAGS to -I... but that didn't work. I also tried calling cmake directly and setting the appropriate -D arguments. I got that to the same point of failure.

Suggestions on how to get the build to find the include tree? I can easily patch files before or after running the configure script (or cmake itself). And in the end the various bits will be installed in /usr/local (or whatever PREFIX is set when the package is built).

Thanks!

    Craig

Hey Craig,

It's been a while! :slight_smile:

Due to the way FreeBSD packages are built at this point zeek is
installed but in /wrkdirs/usr/ports/security/zeek/work/stage/usr/local,
not /usr/local.

As long as the configure/build process is able to find zeek-config, the helper script that reports paths for a given Zeek installation, it shouldn't matter where you have Zeek installed. Is /wrkdirs/usr/ports/security/zeek/work/stage/usr/local/bin in your PATH? zeek-config --include_dir should report the right include trees then.

      post-install-NETMAP-on:
              ${LN} -s ../.build ${WRKSRC}/build
              cd ${WRKSRC_zeek_netmap} && ./configure --zeek-dist=${WRKSRC} \
                  --install-root=${STAGEDIR}${PREFIX}/lib/zeek/plugins
              cd ${WRKSRC_zeek_netmap}/build && make && make install

This is an aside, but I'd advise against using --zeek-dist unless you have to build without an installed Zeek tree. While it should work, source trees shouldn't be required these days to get a build. If you have Zeek installed and zeek-config in your path, I'd hope that a plain

   ./configure && cd build && make

will work. If you also need to point at an alternative location for the Netmap headers, try --with-netmap=.

Let us know how it goes...

Best,
Christian

Hey Craig,

It's been a while! :slight_smile:

Yep! Thanks for the help.

Due to the way FreeBSD packages are built at this point zeek is
installed but in /wrkdirs/usr/ports/security/zeek/work/stage/usr/local,
not /usr/local.

As long as the configure/build process is able to find zeek-config, the helper script that reports paths for a given Zeek installation, it shouldn't matter where you have Zeek installed. Is /wrkdirs/usr/ports/security/zeek/work/stage/usr/local/bin in your PATH? zeek-config --include_dir should report the right include trees then.

It's easy enough to put zeek-config on PATH but it doesn't work because it is configured/built to install in /usr/local but during the packaging process it's actually installed in /wrkdirs/usr/ports/security/zeek/work/stage/usr/local. This causes zeek-config to report the target install dir, not the current actual dir:

     zinc 60 @ /wrkdirs/usr/ports/security/zeek/work/stage/usr/local/bin/zeek-config --include_dir
/usr/local/include:/usr/local/include/zeek:/usr/include:/usr/include:/usr/local/include::
     zinc 61 @ ls /usr/local/include/zeek
     ls: /usr/local/include/zeek: No such file or directory

I tried this:

     post-install-NETMAP-on:
             ${LN} -s ../.build ${WRKSRC}/build
             cd ${WRKSRC_zeek_netmap} && \
                 env PATH=${PATH}:${STAGEDIR}${PREFIX}/bin ./configure \
                 --install-root=${STAGEDIR}${PREFIX}/lib/zeek/plugins
             cd ${WRKSRC_zeek_netmap}/build && make && make install

but it can't find ZeekPlugin. I suspect it's because ZeekPlugin.cmake is in /wrkdirs/.../share/zeek/cmake and not /usr/local/share/cmake (which is what zeek-config --cmake_dir returns).

  post\-install\-NETMAP\-on:
          $\{LN\} \-s \.\./\.build $\{WRKSRC\}/build
          cd $\{WRKSRC\_zeek\_netmap\} &amp;&amp; \./configure \-\-zeek\-dist=$\{WRKSRC\} \\
              \-\-install\-root=$\{STAGEDIR\}$\{PREFIX\}/lib/zeek/plugins
          cd $\{WRKSRC\_zeek\_netmap\}/build &amp;&amp; make &amp;&amp; make install

This is an aside, but I'd advise against using --zeek-dist unless you have to build without an installed Zeek tree. While it should work, source trees shouldn't be required these days to get a build. If you have Zeek installed and zeek-config in your path, I'd hope that a plain

./configure && cd build && make

will work. If you also need to point at an alternative location for the Netmap headers, try --with-netmap=.

I don't understand how --with-netmap works, looking in cmake/FindNetmap.cmake, I think it wants netmap_user.h which is present in /usr/include... But it doesn't find it?

The constraints I'm working under are making it difficult for me to tell cmake where to find things; when building a package, I'm prohibited from making changes to /usr/local but I can do whatever I want to /wrkdirs/usr/ports/security/zeek/work/stage/usr/local. And at package install time things from there get installed in /usr/local.

    Craig

It's easy enough to put zeek-config on PATH but it doesn't work because
it is configured/built to install in /usr/local but during the packaging
process it's actually installed in
/wrkdirs/usr/ports/security/zeek/work/stage/usr/local. This causes
zeek-config to report the target install dir, not the current actual dir:

Ah, I see, thank you ... this sounds a lot like DESTDIR. Something would have to redirect the plugin build and install to that workdir for purposes of the plugin build. zeek-config doesn't currently support that. A few thoughts:

- Going back to your first message, I'm not sure why CXXFLAGS didn't work for you for locating headers -- I just tried a

   CXXFLAGS=-I/path/to/dummy/include ./configure ...

and I can see that directory appear in the build output (via cmake --build build -v). So perhaps the header inclusion actually worked, but you hit other trouble later on?

- You could try patching the generated zeek-config so it prefixes paths with the workdir, and undo that for the version that eventually gets installed. This might be something we need to add to it for this scenario. The paths it reports are all defined right at the top of the script, so it wouldn't be hard to trick it to use the workdir. I don't know if that's enough, though.

- I'm coming back to --zeek-dist now, which should find the required headers. I just tried a build with it and it worked for me ... are you able to point it at the built source tree? I'd suspect it's different from the staged installation.

I don't understand how --with-netmap works, looking in
cmake/FindNetmap.cmake, I think it wants netmap_user.h which is present
in /usr/include... But it doesn't find it?

This might be a detail about the tree layout -- for me, when I say --with-netmap=/foo/bar, it locates netmap_user.h in /foo/bar/include/net/netmap_user.h.

I'm afraid if none of the above helps, you'll need input from somebody who actually uses FreeBSD -- I don't.

Best,
Christian

Btw, there's work underway to simplify building external plugins directly into Zeek: https://github.com/zeek/zeek/pull/1416

That might be another option in the not-too-distant future.

Best,
Christian