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?
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
.
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 throughassert
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 usedcmake
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 usecmake
as it is shown in the file above.