I can only compile and link zstd on CentOS 6 if I add -lrt option to the linker options

[tssajo]

Describe the bug
Compiling and linking zstd on an old Linux system such as CentOS 6 gives the following error when running make:

LINK obj/conf_aec26574c336b900571a5deec4052692/zstd
obj/conf_aec26574c336b900571a5deec4052692/timefn.o: In function `UTIL_getTime':
timefn.c:(.text+0x5e): undefined reference to `clock_gettime'
obj/conf_aec26574c336b900571a5deec4052692/timefn.o: In function `UTIL_clockSpanNano':
timefn.c:(.text+0xb2): undefined reference to `clock_gettime'
obj/conf_aec26574c336b900571a5deec4052692/timefn.o: In function `UTIL_clockSpanMicro':
timefn.c:(.text+0x112): undefined reference to `clock_gettime'
obj/conf_aec26574c336b900571a5deec4052692/timefn.o: In function `UTIL_waitForNextTick':
timefn.c:(.text+0x190): undefined reference to `clock_gettime'
timefn.c:(.text+0x1ca): undefined reference to `clock_gettime'
collect2: ld returned 1 exit status
make[2]: *** [obj/conf_aec26574c336b900571a5deec4052692/zstd] Error 1
make[1]: *** [zstd] Error 2
make[1]: Leaving directory `zstd-1.5.4/programs'
make: *** [zstd-release] Error 2

To Reproduce
Steps to reproduce the behavior:

1. Download zstd-1.5.4.tar.gz on CentOS 6
2. Extract with tar xf zstd-1.5.4.tar.gz
3. cd into zstd-1.5.4 directory: cd zstd-1.5.4
4. Run make
5. See error

Expected behavior
zstd build process should complete without errors

Desktop (please complete the following information):

• OS: CentOS
• Version 6
• Compiler: gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC)
• Build system: make --version = GNU Make 3.81

The fix:
In zstd-1.5.4/programs directory I patched Makefile like this:

--- Makefile.orig       2023-02-10 01:41:50.000000000 +0100
+++ Makefile    2023-03-17 18:46:15.742527719 +0100
@@ -159,7 +159,7 @@
        @echo "$(LZMA_MSG)"
        @echo "$(LZ4_MSG)"
        @echo LINK $@
-       $(CC) $(FLAGS) $^ $(LDLIBS) -o $@$(EXT)
+       $(CC) $(FLAGS) $^ $(LDLIBS) -lrt -o $@$(EXT)

 ifeq ($(HAVE_HASH),1)
 SRCBIN_HASH = $(shell cat $(BUILD_DIR)/zstd$(EXT) 2> $(VOID) | $(HASH) | cut -f 1 -d " ")

[Cyan4973]

Would LDLIBS=-lrt make work ?

[tssajo]

Yes, it worked, so no file patching is needed.

However, since yesterday I noticed a much more important bug: zstd 1.5.4 segfaults on CentOS 6 !

[Cyan4973]

Care to elaborate ?
Maybe both issues are related.

[sb22bs]

Possible workarounds:

LDLIBS=-lrt CFLAGS="-O3 -mno-sse2" make V=1
LDLIBS=-lrt CFLAGS="-O3 -fno-inline" make V=1

It seems to be a bug in gcc-4.4.7, gcc-4.8.5 works.
/proc/cpuinfo: Intel Nehalem
model name : Intel(R) Xeon(R) CPU L5520 @ 2.27GHz

"-O3 -g" and then doing a "zstd -b"

(gdb) info stack
#0  0x00000000004053b3 in MEM_write64 (ct=0x7f92d663ce20, normalizedCounter=0x7f92d663dce4, maxSymbolValue=16, tableLog=8,
    workSpace=0x7f92d663dd50, wkspSize=<value optimized out>) at ../lib/compress/../common/mem.h:199
#1  FSE_buildCTable_wksp (ct=0x7f92d663ce20, normalizedCounter=0x7f92d663dce4, maxSymbolValue=16, tableLog=8, workSpace=0x7f92d663dd50,
    wkspSize=<value optimized out>) at ../lib/compress/fse_compress.c:130
#2  0x000000000041da5b in ZSTD_buildCTable (dst=0x7f92d710a4a8, dstCapacity=10005118, nextCTable=0x7f92d663ce20, FSELog=<value optimized out>,
    type=<value optimized out>, count=<value optimized out>, max=16,
    codeTable=0x7f92d673ff28 "\003\005\005\003\005\004\a\a\005\004\004\003\003\006\004\b\t\t\t\n\003\005\t", nbSeq=2508, defaultNorm=0x4c8500,
    defaultNormLog=5, defaultMax=28, prevCTable=0x7f92d663b820, prevCTableSize=772, entropyWorkspace=0x7f92d663dce4, entropyWorkspaceSize=8708)
    at ../lib/compress/zstd_compress_sequences.c:282
#3  0x00000000004103b4 in ZSTD_buildSequencesStatistics (seqStorePtr=<value optimized out>, nbSeq=2508, prevEntropy=0x7f92d663b820,
    nextEntropy=0x7f92d663ce20,
    dst=0x7f92d710a48f "\324\315aa\001\202\201\221X$\020\210\004B\221P(\020\b\a\363,\222\252\rc\020\210\200@\030\020\f\a\006䢊\312\017",
    dstEnd=0x7f92d7a94f26 "01020030032302501212000200102002330020123000310002511100001000100113010110200201200010100100101210000001032107000301241111721110200000202101152160100010001020402023002000113300007110000000060033003011"..., strategy=ZSTD_dfast, countWorkspace=0x7f92d663dc10,
    entropyWorkspace=0x7f92d663dce4, entropyWkspSize=8708) at ../lib/compress/zstd_compress.c:2720
#4  0x0000000000410d6e in ZSTD_entropyCompressSeqStore_internal (seqStorePtr=0x2079668, prevEntropy=<value optimized out>,
    nextEntropy=<value optimized out>, cctxParams=0x20793b0, dst=0x7f92d710201d, dstCapacity=10039049, srcSize=131072,
    entropyWorkspace=0x7f92d663dc10, bmi2=0, entropyWkspSize=8920) at ../lib/compress/zstd_compress.c:2858
#5  ZSTD_entropyCompressSeqStore (seqStorePtr=0x2079668, prevEntropy=<value optimized out>, nextEntropy=<value optimized out>,
    cctxParams=0x20793b0, dst=0x7f92d710201d, dstCapacity=10039049, srcSize=131072, entropyWorkspace=0x7f92d663dc10, bmi2=0,
    entropyWkspSize=8920) at ../lib/compress/zstd_compress.c:2908
#6  0x0000000000414f64 in ZSTD_compressBlock_internal (zc=0x20792d0, dst=<value optimized out>, dstCapacity=10039049, src=0x7f92d7a96010,
    srcSize=131072, frame=1) at ../lib/compress/zstd_compress.c:4195
#7  0x0000000000415331 in ZSTD_compress_frameChunk (cctx=0x20792d0, dst=0x7f92d710201a, dstCapacity=10039052, src=<value optimized out>,
    srcSize=10000000, frame=<value optimized out>, lastFrameChunk=1) at ../lib/compress/zstd_compress.c:4385

[...]

It looks like the inlining of MEM_write64 doesn't work out with gcc-4.4.7.
objdump-no-crash-O3-no-sse2.asm.txt
objdump-no-crash-O3-gcc-4.8.5.asm.txt
objdump-crash-O3.asm.txt
objdump-no-crash-O3-noinline.asm.txt

[sb22bs]

so basically 64-bit-memory-access and unaligned stack are not a very good combination
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27537
(the problem is not restricted to nehalem, it's just a "sse2/mmx" constraint, and gcc-4.4.7 just doesn't do the right thing)

$ grep xmm objdump-crash-O3.asm.txt                                    
  0x0000000000405397 <+807>:	movq   -0x58(%rsp),%xmm1
  0x00000000004053a4 <+820>:	punpcklqdq %xmm1,%xmm1
  0x00000000004053a8 <+824>:	movdqa %xmm1,%xmm0
  0x00000000004053b3 <+835>:	movdqa %xmm0,(%rbx)

[tssajo]

@sb22bs Thank you so much for your analysis. I installed gcc version 4.9.1 on CentOS 6 then compiled and installed zstd with the following command: LDLIBS=-lrt make install and now it works perfectly. It is no longer crashing. So I close this Issue.

[grossag]

What flag should we pass into the cmake build to work around this issue?

[Cyan4973]

cmake -D CMAKE_EXE_LINKER_FLAGS="-lrt" .

[grossag]

That works, thanks so much @Cyan4973 !

[tssajo]

@sb22bs @Cyan4973 Unfortunately, version 1.55 is crashing again on CentOS 6 ( I know, it's old ) ...
zstd 1.54 worked fine on CentOS 6 with gcc version 4.9.1 but now zstd 1.55 is crashing. The same way as zstd 1.54 used to crash when compiled with older compilers.

[tssajo]

Sorry, I just realized that if I compile with gcc version 4.9.x then it works.