Xxhash: [cmake] avoid reference to `xxhsum` build directory

Created on 1 Aug 2018  ·  7Comments  ·  Source: Cyan4973/xxHash

Hello,
I'm making (unofficial) package for Archlinux (my distribution) and makepkg (the distro package build tool) warns me that xxhsum has reference to build directory.

I checked that with

$ strings xxhsum | grep BUILD_DIR

and found only one occurrence. I tried to build the package with --save-temps flag for gcc and found the BUILD_DIR in xxhsum.o.s file. I don't understand the format of that file but according to surroundings of the string it somehow might be related to XXXbenchHash function. Unfortunately, I couldn't figure out how that string comes to the xxhsum, I don't see any usage of special macros there.

I would like to get rid of this string (see, for example, "reproducible builds") but now I'm lost and don't have any clue what to do further. Does anyone has idea how to get rid of this string in compiled binary or know how to debug the problem?

build issue help wanted

Most helpful comment

Hello,
for the record, I found the reason and workaround for the issue. In short: use the following CMakeLists.txt file and put it in top directory.

Long story: the reference to the source directory is due to __FILE__ macro in all its forms. In this particular case it sneaks through assert macro. If one compiles the project within source directory there is no problem because in this case __FILE__ is expanded (by compiler) to a relative path. But one of the most used cmake feature is compilation outside of source directory and in that case compiler expands the __FILE__ macro to full path. However, it is possible to use paths relative to source directory but one has to redefine __FILE__ macro. One may use cmake as it is shown in the file above.

All 7 comments

That's pretty strange.
There's nothing within xxhsum.c source code susceptible to generate a reference to BUILD_DIR.

I compiled it on a Linux mint vm, and made the same check as you :

$ strings xxhsum | grep BUILD_DIR
$

It did not returned anything.

It might be an artifact of the build system.

I suppose that you use actual directory instead of BUILD_DIR, don't you? If you do then you may be right, this is artifact of my build tool. I'll try different system to check this out. As for my current system I can reproduce this manually:

$ cd DIR_WITH_UNPACKED_SOURCE
$ mkdir build
$ cmake ../xxHash-0.6.5
$ make
$ strings xxhsum | grep BUILD_DIR
BUILD_DIR:
DIR_WITH_UNPACKED_SOURCE/xxHash-0.6.5/xxhsum.c

Environment: bash 4.4.023, gcc 8.1.1 20180531, binutils 2.30, cmake 3.11.4, make 4.2.1, glibc 2.27.

Ah, I haven't tested cmake, and it might be introducing this issue.
I only tested the simpler make build process :

$ cd XXH_SRC_DIR
$ make
$ strings xxhsum | grep BUILD_DIR
$

cmake is 3rd-party maintained (hence the "unofficial" tag), I don't understand all its internals and side-effects, unfortunately, and only officially maintain Makefile.

Hello,
for the record, I found the reason and workaround for the issue. In short: use the following CMakeLists.txt file and put it in top directory.

Long story: the reference to the source directory is due to __FILE__ macro in all its forms. In this particular case it sneaks through assert macro. If one compiles the project within source directory there is no problem because in this case __FILE__ is expanded (by compiler) to a relative path. But one of the most used cmake feature is compilation outside of source directory and in that case compiler expands the __FILE__ macro to full path. However, it is possible to use paths relative to source directory but one has to redefine __FILE__ macro. One may use cmake as it is shown in the file above.

Hello!
I beleave assert macro should be defined as (void)0 if NDEBUG is defined.

NDEBUG is defined automatically by CMake if CMAKE_BUILD_TYPE is set to _"Release"_ (for single-configuration generators like Unix Makefiles) or if building project with --config Release option (for multiconfiguration generators like Xcode).
For _"RelWithDebInfo"_ build type one should define NDEBUG by own in sources or in CMake lists.
I've tested it just now.

Good luck!

The logic for assert has been updated, and is defined here :
https://github.com/Cyan4973/xxHash/blob/dev/xxhash.c#L146

By default, all asserts in xxhash are disabled.
To enable them, it's required to set DEBUGLEVEL to a value >= 1.
Even in this case, assert() can still be disabled by setting NDEBUG.

Whatever the value of DEBUGLEVEL,
NDEBUG setting will not be modified,
it remains exactly the same after including xxhash code
(typically with XXH_INLINE_ALL, which is the most impactful build type).

I believe this issue has been fixed.
I tested a cmake-produced xxhsum on a Linux system using strings, and it couldn't find any reference to BUILD_DIR.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

Leandros picture Leandros  ·  15Comments

easyaspi314 picture easyaspi314  ·  21Comments

amadio picture amadio  ·  16Comments

tonda-kriz picture tonda-kriz  ·  33Comments

DonaldTsang picture DonaldTsang  ·  17Comments