intel / intel/hyperscan

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

Open
#344 10 comments 0 reactions 0 assignees View on GitHub
Dominant language
C++
Stars
5.5k
Forks
816
Avg merge
4d 21h
Merged PRs (30d)
2

Description

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](https://github.com/intel/hyperscan/files/7803970/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](https://src.fedoraproject.org/rpms/hyperscan/blob/rawhide/f/hyperscan-5.4.0-build_wrapper_fix.patch) 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](https://github.com/intel/hyperscan/files/7803977/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.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.