[cmake] avoid reference to `xxhsum` build directory

vp1981 commented

2018-08-01 04:50:16 -05:00

(Migrated from github.com)

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?

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?

Cyan4973 commented

2018-08-01 07:49:54 -05:00

(Migrated from github.com)

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.

That's pretty strange. There's nothing within [`xxhsum.c`](https://github.com/Cyan4973/xxHash/blob/dev/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 : ```bash $ strings xxhsum | grep BUILD_DIR $ ``` It did not returned anything. It might be an artifact of the build system.

vp1981 commented

2018-08-01 09:07:53 -05:00

(Migrated from github.com)

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.

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.

Cyan4973 commented

2018-08-01 09:43:18 -05:00

(Migrated from github.com)

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.

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`.

vp1981 commented

2018-08-07 04:09:23 -05:00

(Migrated from github.com)

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, for the record, I found the reason and workaround for the issue. In short: use the following [```CMakeLists.txt```](https://gist.github.com/vp1981/a1850615db33e0575fb153d835498b18) 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.

👍 2

Mezozoysky commented

2019-07-29 12:43:38 -05:00

(Migrated from github.com)

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!

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!

Cyan4973 commented

2019-08-05 09:53:21 -05:00

(Migrated from github.com)

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).

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).

Cyan4973 commented

2020-02-10 17:42:18 -06:00

(Migrated from github.com)

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.

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`.

Rows
Columns

[cmake] avoid reference to xxhsum build directory #145

[cmake] avoid reference to `xxhsum` build directory #145