The library generated by the CMakeLists file rules may have import problems.

[CandyMi]

A little suggestion about CMakeLists File:

• Is it possible to use a macro to decide whether to ignore RPATH?

• To determine whether xxhash can consider using find_package?

[dtikhonov]

Thank you for the suggestions. The current setup works well for us. Could you please elaborate:

1. What is RPATH and why should one ignore it (or not)?
2. I don't think xxhash has been packaged for any platform, it's too small -- or has it?

[gstrauss]

xxhash has been packaged in Fedora since Fedora 31, some three years ago. https://src.fedoraproject.org/rpms/xxhash

xxhash has been packaged in Debian since Debian 9 Stretch, released almost two years ago. https://tracker.debian.org/pkg/xxhash

(This is not a complete list, but merely a 2 out of 2 positive hit for presence of xxhash packages)

[CandyMi]

First, If you need to rely on third-party libraries, then RPATH should add some search paths, such as: /usr/local or /usr/local/opt, etc.

Secondly, since we all think that xxhash is already a mature product. This should be considered to be included in the find_package scope instead of copy alone

[dtikhonov]

I stand corrected! Indeed, xxhash is packaged for Ubuntu as well.

Regarding xxhash being a mature product: the API may be the same, but ls-hpack relies on particular values of xxhash internally. How can we guarantee that the installed version of xxhash will produce the same values?

And I still don't know what RPATH is.

Let's do this: if you have a specific improvement in mind, please propose a PR.

[gstrauss]

Regarding xxhash being a mature product: the API may be the same, but ls-hpack relies on particular values of xxhash internally.

ls-hpack/deps/xxhash/xxhash.[ch] appears to come from https://github.com/Cyan4973/xxHash near d8c04c12 (and then someone edited, or someone's editor modified some formatting in ls-hpack/deps/xxhash/xxhash.[ch]) Other than some formatting changes, the code is identical, and commit d8c04c12 is very, very, very old (23 Nov 2014).

Newer versions of xxhash move the implementation into xxhash.h, and work with ls-hpack in my tests against xxhash tag: v0.8.0

@dtikhonov is there a unit test in ls-hpack which can be used to validate the hard-coded hash values in ls-hpack?

[CandyMi]

-Wl,-rpath specifies that the dynamic library will be searched for dependent library path only when it is run or imported.

Previously, I suggested to use find_package to check dependent libraries (xxhash), which is to use -Wl,-rpath.

The package management used by different operating systems and its installation path will also be different, I would think that using the rpath specification is the easiest choice.

Please tell me if there is a better way, because I will only use this way. :)

[gstrauss]

@CandyMi please re-read the posts by @dtikhonov in which he clearly states that this is not his area of expertise. He politely requested that you propose a patch.

[dtikhonov]

is there a unit test in ls-hpack which can be used to validate the hard-coded hash values in ls-hpack?

test/test_hpack.c should do that. To check, I just changed the seed, recompiled, and all tests failed.

[gstrauss]

Slightly off-topic, but important if using a different library version of xxHash: FYI: I updated deps/xxhash/xxhash.[ch] to versions from xxHash tag v0.8.0. make test passes all tests, so the hash calculations must produce the same results. (However, that I was able to run the tests only after I commented out some code in auxilary program bin/calc-xxh.c, which no longer compiles with xxHash v0.8.0 due to XXH32_state_t no longer being a complete public type.)