hyperscan library cause load shared libraries error about hyperscan HOT 7 OPEN

The unexpected PLT reloc type 0x25 error that you got indicates that the ld-linux on that system does not support the R_X86_64_IRELATIVE relocation type which is required for the indirect functions (ifunc) that the fat runtime uses.

Glibc 2.5 is from 2006, and is far too old to support the use of the fat runtime.

from hyperscan.

I think if the CMakeLists.txt of hyperscan could do some GLibc version check. It will prevent this issue happens, since too old GLibc shouldn't open FAT_RUNTIME option.

from hyperscan.

I think this is most likely due to the way you're trying to statically link libstdc++ -- are you able to build your binary with:

# gcc -I/home/deps/dest/usr/local/include/hs  simplegrep.c \
    /home/deps/dest/usr/local/lib64/libhs.a -lstdc++ -lm

Are you building libhs.a on the same machine with the same toolchain?

from hyperscan.

@jviiret Thanks for quick reply. With -lstdc++, still error:

[root@05c8ec243f3d /home/yiwei.liyw/test/hyperscan-4.5.2/examples]
#gcc -I/home/deps/dest/usr/local/include/hs  simplegrep.c /home/deps/dest/usr/local/lib64/libhs.a -lstdc++ -lm

[root@05c8ec243f3d /home/yiwei.liyw/test/hyperscan-4.5.2/examples]
#./a.out
./a.out: error while loading shared libraries: unexpected PLT reloc type 0x25

Are you building libhs.a on the same machine with the same toolchain?

Yes! I'm using exactly the same gcc/binutils/glibc to compile simplegrep.c.

from hyperscan.

@jviiret Oh, I have compiled libhs.a with FAT_RUNTIME=OFF, and the problem is gone. So maybe it's an issue about fat runtime. Is there anyone who can look into it?

from hyperscan.

@mdb256 Would you please look at this issue for a moment? Thank you very much.

from hyperscan.

@mdb256 Thanks for the quick reply. I will evaluate if our program could work without fat runtime support and make some necessary changes.

from hyperscan.