>>89Thanks for trying it out.
I recall someone mentioning the perils of backticks on the suckless mailing list. They also mentioned a linting tool that checks shell scripts for compliance. Can't find the email now though.
As for the problem with LTO, in GCC 4.9 they introduced a new slim LTO format which broke backward compatibility with the traditional tool chain. I think Clang/LLVM 3.9 just added support for it as well. Anyway, new tool front-ends were introduced for working with slim LTO objects, gcc-ar, gcc-ranlib, gcc-nm which all call ar, ranlib, and nm with the addition LTO plugin arguments.
Fix it locally by modifying the AR and RANLIB variables to use gcc-ar and gcc-ranlib in config.mk or on the command line or remove -flto from the CFLAGS variable.
The reason I haven't changed this to be the default yet is that it breaks things on FreeBSD 10 and one of my other build machines running an old Ubuntu 14.10 LTS install. Not sure of the best way to go forward here. Multiple config.mk files? Dynamically detect if gcc-ar and gcc-ranlib are accessible form PATH in the Makefile using the shell assignment operator?
I don't care about POSIX compliance for the makefiles, just GNU make and bmake cross compatibility.