3.2.0 Fails to build on Alpine Linux

[fazalmajid]

g++ -g -O2 -fno-exceptions -fno-rtti -O2 -I/usr/local/include -I/usr/local/ssl/include -UHAVE_SIMD -c -o simd-checksum-x86_64.o ./simd-checksum-x86_64.cpp
./simd-checksum-x86_64.cpp: In function 'uint32_t get_checksum1_cpp(char*, int32_t)':
./simd-checksum-x86_64.cpp:88:52: error: multiversioning needs ifunc which is not supported on this target
   88 | __attribute__ ((target("default"))) MVSTATIC int32 get_checksum1_avx2_6(schar* buf, int32 len, int32 i, uint32* ps1, uint32* ps2) { return i; }
      |                                                    ^~~~~~~~~~~~~~~~~~~~
./simd-checksum-x86_64.cpp:474:1: error: use of multiversioned function without a default
  474 | }
      | ^
./simd-checksum-x86_64.cpp:89:52: error: multiversioning needs ifunc which is not supported on this target
   89 | __attribute__ ((target("default"))) MVSTATIC int32 get_checksum1_ssse3_32(schar* buf, int32 len, int32 i, uint32* ps1, uint32* ps2) { return i; }
      |                                                    ^~~~~~~~~~~~~~~~~~~~~~
./simd-checksum-x86_64.cpp:474:1: error: use of multiversioned function without a default
  474 | }
      | ^
gmake: *** [Makefile:135: simd-checksum-x86_64.o] Error 1

I'm guessing that's because ifunc is a glibc feature, which would not work on a Linux that uses non-GNU libc like Alpine with musl libc.

The same error occurs on SmartOS.

[WayneD]

You can use --disable-simd configure option.

[fazalmajid]

It also fails on OS X 10.14 Mojave, even if you remove HAVE_SIMD. The error is a bit different:

gcc -c -o lib/md5-asm-x86_64.o ./lib/md5-asm-x86_64.s
./lib/md5-asm-x86_64.s:31:1: error: unknown directive
.type md5_process_asm,@function
^
./lib/md5-asm-x86_64.s:693:1: error: unknown directive
.size md5_process_asm,.L_md5_process_asm_end-md5_process_asm
^
gmake: *** [Makefile:138: lib/md5-asm-x86_64.o] Error 1

[WayneD]

Don't remove HAVE_SIMD, re-run configure with --disable-simd. The macOS issue should be fixed in master already, BTW.

[fazalmajid]

OK, thanks!

I will wait for the next release (3.2.1?) to rebuild on Darwin.

[WayneD]

It would be helpful if you'd test the latest master branch, if possible.

I've changed the configure check to do a compile test and not try to use SIMD if it fails.

[WayneD]

It would also be nice if some of the SIMD contributers would also give the latest configure.ac setup a try and see what you think. My latest version will give folks w/o a c++ a pass (it won't try to force them to supply a compiler) but I think that's OK as it should also not hassle them if their compiler can't build the test source. Thanks!

@Chainfire @benrubson @eworm-de @hhoffstaette

[fazalmajid]

OS X Mojave compile still fail in the master branch if you don't supply --without-simd. It does build properly with --without-simd. Perhaps the SIMD configure test should also verify libc is glibc, or the code be changed not to rely on multiversioning.

Here is the error without --with-simd. clang actually segfaults:

g++ -I. -g -O2 -fno-exceptions -fno-rtti -I/usr/local/ssl/include -O2 -c -o simd-checksum-x86_64.o ./simd-checksum-x86_64.cpp
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple clang version 11.0.0 (clang-1100.0.33.17)
Target: x86_64-apple-darwin18.7.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/bg/2gzxvhm16w3bbgnm2_22p_xc0000z9/T/simd-checksum-x86_64-6a14df.cpp
clang: note: diagnostic msg: /var/folders/bg/2gzxvhm16w3bbgnm2_22p_xc0000z9/T/simd-checksum-x86_64-6a14df.sh
clang: note: diagnostic msg: /var/folders/bg/2gzxvhm16w3bbgnm2_22p_xc0000z9/T/simd-checksum-x86_64-6a14df.crash
clang: note: diagnostic msg: 

********************
gmake: *** [Makefile:135: simd-checksum-x86_64.o] Error 254

[WayneD]

A glibc test is a non-starter because we also work fine on BSD. We really just need to get the configure test to fail if it's not going to work. I already verified that it properly disables simd on Alpine. I'm adding an echo in the build sequence to make sure that folks know about --disable-simd should they manage to get a successful test but an unsuccessful build.

[WayneD]

I made the configure test now actually link & run the program, not just compile it. Hopefully that will make your Mohave setup ignore the simd code.

[debohman]

Yes, I have run into the clang++ crash when compiling ./simd-checksum-x86_64.cpp. I am using the public llvm-10.0.0 release.

If you remove the -g or the -O2 from the compile command, it compiles successfully. As a workaround invoke ./configure as such to remove the -g:

CXXFLAGS=-O2 ./configure

I plan to file a bug against llvm/clang++ about this once they give me a bug reporting account.

[WayneD]

My latest commit removes the -g option from the CXXFLAGS, since it's only the one file (and if we need to debug it, we can manually add it back). Feel free to try out the master branch and see if that builds w/o error for you.

[debohman]

The llvm/clang++ crash is clearly their bug, because it should never crash, regardless of what you feed to it. I am saving the preprocessed input and the invocation information, and I will file a bug with them as soon as they give me an account.

I will try out the top of tree shortly.

[debohman]

With the top of tree, the simd test for configure crashes llvm/clang++ 10.0.0.

I worked around it by supplying CXXFLAGS=-O2 on the configure line. My full line is now:

CPPFLAGS=-I/usr/local/include CXXFLAGS=-O2 LDFLAGS=-L/usr/local/lib ./configure

The problem is that now, it does not find SIMD at runtime judging with rsync --version. I am using Westmere-EP processors, which have SSE4.2.