You're right on both counts -- I was able to compile successfully with
-DFAT_RUNTIME=off, and my symbols look like so:
$ nm CMakeFiles/hs_exec_avx2.dir/src/crc32.c.o
0000000000000000 T Crc32c_ComputeBuf
I'm not so concerned with figuring out why the fat runtime isn't building
at this point. I'm happy to pass along other system details if it helps you
debug the issue, though.
$ dpkg -s gcc | grep Version
$ dpkg -s binutils | grep Version
$ dpkg -s libc6 | grep Version
Date: Thu, 23 Feb 2017 21:57:06 +0000
From: "Barr, Matthew" <matthew.barr(a)intel.com>
To: Hyperscan regular expression matching library
Subject: Re: [Hyperscan] Compile fails at unit-hyperscan stage
Content-Type: text/plain; charset="utf-8"
From: Hyperscan [mailto:email@example.com] On Behalf Of Matt
Sent: Friday, February 24, 2017 2:56 AM
> Any idea what's causing this?
> ../lib/libhs.a(dispatcher.c.o): In function `resolve_hs_scan':
> /home/mgrimm/hyperscan-git/src/dispatcher.c:66: undefined reference to
One of the things we added to Hyperscan v4.4 was what we call the fat
runtime. Essentially this is three copies of the runtime code for
Hyperscan, each built for a different target microarchitecture. When an
application that is linked to the Hyperscan library is executed we check
the host machine (in dispatcher.c), and based on what microarch is present,
we set up the best of those runtime copies.
So that explains the three variants of hs_scan, etc, that the linker can't
My best guess is that something has gone wrong when we are building the
three copies of the runtime code. Right now the symbol mangling is done
with a helper script (cmake/build_wrapper.sh) that goes looking for symbols
in each .o that is built and rewrites them using objcopy. I'm responsible
for creating that script and I know it could be better.
After explaining all of that, you can disable the fat runtime build by
running 'cmake -DFAT_RUNTIME=off .' in your build dir, and then recompiling.
Figuring out why the fat runtime isn't building might take longer - but we
do a lot of testing on Ubuntu 14.04, so that combination of gcc, binutils
and glibc should be absolutely fine.
For the first step, if you look at the symbols in the first file built,
using "nm CMakeFiles/hs_exec_avx2.dir/src/crc32.c.o" you should see the
single entry for "avx2_Crc32c_ComputeBuf" - my guess is that it doesn't
have the "avx2_" prefix, correct?