hyperscan fails to build - casading "undefined reference" errors on step "Linking CXX executable ../bin/unit-hyperscan

[da667]

Hi there.

I'm running into a problem building hyperscan on Ubuntu 21.10. This is an ESXi virtual machine. Here is the relevant information about the system, if it helps at all:

disk: 60GB ram:2GB cpu: 1vCPU

lsb_release -a:
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 21.10
Release:        21.10
Codename:       impish

uname -a:
Linux short-term-test 5.13.0-22-generic #22-Ubuntu SMP Fri Nov 5 13:21:36 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

cat /proc/cpuinfo:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 63
model name      : Intel(R) Xeon(R) CPU E5-2609 v3 @ 1.90GHz
stepping        : 2
microcode       : 0x43
cpu MHz         : 1895.432
cache size      : 15360 KB
physical id     : 0
siblings        : 1
core id         : 0
cpu cores       : 1
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 15
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon nopl xtopology tsc_reliable nonstop_tsc cpuid tsc_known_freq pni pclmulqdq ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp fsgsbase tsc_adjust bmi1 avx2 smep bmi2 invpcid xsaveopt arat md_clear flush_l1d arch_capabilities
bugs            : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs itlb_multihit
bogomips        : 3790.86
clflush size    : 64
cache_alignment : 64
address sizes   : 45 bits physical, 48 bits virtual
power management:

Here are the cmake configuration options I'm using: sudo cmake -DCMAKE_INSTALL_PREFIX=/usr/local -DBOOST_ROOT=/home/ayy/boost_1_78_0

The reason I'm building hyperscan from source is mainly due to the recommendation of a guide on how to compile snort3 on Ubuntu 20.04 -- They recommend compiling against hyperscan's source, with the C++ boost source available as well. See the guide here [PDF]: https://snort.org/documents/snort-3-1-17-0-on-ubuntu-18-20

The cmake command and the configuration options passed to it work fine. Then I run sudo make to continue building hyperscan, and it reaches the stage:

[ 86%] Linking CXX executable ../bin/unit-hyperscan

..then I get a huge stack trace of undefined reference errors. I've taken the liberty of attaching an output file from the tee command, containing stdout and stderr. Here is a selection of the errors:

/usr/bin/ld: ../lib/libhs.a(limex_native.c.o): in function `memset':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: ../lib/libhs.a(limex_64.c.o): in function `memset':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: ../lib/libhs.a(limex_64.c.o):/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: more undefined references to `core2_memset' follow
/usr/bin/ld: ../lib/libhs.a(limex_simd128.c.o): in function `memcpy':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29: undefined reference to `core2_memcpy'
/usr/bin/ld: ../lib/libhs.a(limex_simd128.c.o): in function `memset':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: ../lib/libhs.a(limex_simd128.c.o): in function `memcpy':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29: undefined reference to `core2_memcpy'
/usr/bin/ld: ../lib/libhs.a(limex_simd128.c.o): in function `memset':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: ../lib/libhs.a(limex_simd256.c.o): in function `memcpy':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29: undefined reference to `core2_memcpy'
/usr/bin/ld: ../lib/libhs.a(limex_simd256.c.o): in function `memset':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: /usr/include/x86_64-linux-gnu/bits/string_fortified.h:59: undefined reference to `core2_memset'
/usr/bin/ld: ../lib/libhs.a(limex_simd256.c.o): in function `memcpy':
/usr/include/x86_64-linux-gnu/bits/string_fortified.h:29: undefined reference to `core2_memcpy'

and here is the complete log (hyperscan_make.log):

hyperscan_make.log

Now, I did a little due diligence and I looked at a couple of other issues by searching for "Linking CXX executable" I looked at #339 , and looked at the patched build_wrapper.sh file, and implemented the change in the build_wrapper file manually. The same failure occurred. Here is a log of that stack trace (hyperscan_make_patch.log)

hyperscan_make_patch.log

I also looked at #275 , and it looks like that ticket is hanging open with no resolution and no further input from the user that opened it.

I'm totally open to suggestions or helping with troubleshooting as necessary. I can also confirm that compiling hyperscan on an identically spec'd virtual machine works perfectly fine on Ubuntu 20.04.

Thank you in advance.

[da667]

So I did a little bit more poking around with this. A friend of mine suggested that I try running cmake with the -DFAT_RUNTIME=false argument In addition to the previous arguments I specified. Well, I did, and while it still errors out, the stack trace is much more succint now:

[ 96%] Building CXX object tools/hscollider/CMakeFiles/hscollider.dir/sig.cpp.o
In file included from /usr/include/signal.h:328,
                 from /usr/src/hyperscan-v5.4.0/tools/hscollider/sig.cpp:40:
/usr/src/hyperscan-v5.4.0/tools/hscollider/sig.cpp:178:40: error: size of array ‘alt_stack_loc’ is not an integral constant-expression
  178 | static TLS_VARIABLE char alt_stack_loc[SIGSTKSZ];
      |                                        ^~~~~~~~
make[2]: *** [tools/hscollider/CMakeFiles/hscollider.dir/build.make:217: tools/hscollider/CMakeFiles/hscollider.dir/sig.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:773: tools/hscollider/CMakeFiles/hscollider.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

I'm not a developer by any stretch of the imagination, I'm just a layperson trying to help where I can. Googling for this error seems to indicate that something has changed with gcc in which the extension for C++ that supports variable length arrays is... not working properly. If you have any thoughts, I'm all for it.

In the meantime, I've discovered that Canonical provides a pre-compiled package for hyperscan. I've found that for my purposes that simply running apt-get install libhyperscan-dev satisfies the requirements such that Snort 3 WILL compile on Ubuntu 21.10, and is able to utilize hyperscan (verified by running snort -V).

I'm still leaving this open because I would like some assistance on being able to compile this on 21.10. I have a feeling that if this is related to updates to gcc/g++, that this is probably going to be a problem for the next Ubuntu LTS release as well.

[schmorp]

This happens for hyperscan 5.4.0 and 5.3.0 regardless of fat binary support or not. Hyperscan 5.2.1 is the last release that builds for me.

[balusch]

Same issue and even v5.2.1 still not works.

[balusch]

But with -DFAT_RUNTIME=off option specified, it works for master branch.

[MutableLoss]

Ran into this as well with Debian 11 with 5.4.0. Is there any way to build this and retain the AVX512 support for the fast pattern matching?

[ZhouWenchang]

I change my python preference from python3 to python2 and it works.

[hongyang7]

So I did a little bit more poking around with this. A friend of mine suggested that I try running cmake with the -DFAT_RUNTIME=false argument In addition to the previous arguments I specified. Well, I did, and while it still errors out, the stack trace is much more succint now:

[ 96%] Building CXX object tools/hscollider/CMakeFiles/hscollider.dir/sig.cpp.o
In file included from /usr/include/signal.h:328,
                 from /usr/src/hyperscan-v5.4.0/tools/hscollider/sig.cpp:40:
/usr/src/hyperscan-v5.4.0/tools/hscollider/sig.cpp:178:40: error: size of array ‘alt_stack_loc’ is not an integral constant-expression
  178 | static TLS_VARIABLE char alt_stack_loc[SIGSTKSZ];
      |                                        ^~~~~~~~
make[2]: *** [tools/hscollider/CMakeFiles/hscollider.dir/build.make:217: tools/hscollider/CMakeFiles/hscollider.dir/sig.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:773: tools/hscollider/CMakeFiles/hscollider.dir/all] Error 2
make: *** [Makefile:149: all] Error 2

I'm not a developer by any stretch of the imagination, I'm just a layperson trying to help where I can. Googling for this error seems to indicate that something has changed with gcc in which the extension for C++ that supports variable length arrays is... not working properly. If you have any thoughts, I'm all for it.

In the meantime, I've discovered that Canonical provides a pre-compiled package for hyperscan. I've found that for my purposes that simply running apt-get install libhyperscan-dev satisfies the requirements such that Snort 3 WILL compile on Ubuntu 21.10, and is able to utilize hyperscan (verified by running snort -V).

I'm still leaving this open because I would like some assistance on being able to compile this on 21.10. I have a feeling that if this is related to updates to gcc/g++, that this is probably going to be a problem for the next Ubuntu LTS release as well.

This is related to #359 , a changed glibc feature. We're considering a patch.

[rx8driver]

so, any resolution to this? the issue is still present as of today. I guess the only workaround is going to be to use the libhyperscan-dev package and we are accepting this can no longer be built on Ubuntu without using an old version?