Build fails on Slackware LInux

[next-mad-hatter]

It seems when llvm was built using clang, llvm-config --cxxflags can produce options gcc-g++ does not understand [1], hence attempting to build crystal from source fails with errors like

g++: error: unrecognized command line option '-Wcovered-switch-default'

On a related note, on multilib Slackware the 64bit libraries reside in /usr/lib64 while the prebuilt x86_64 crystal version attempts to use /usr/lib and fails with errors like

/usr/lib64/gcc/x86_64-slackware-linux/5.5.0/../../../../x86_64-slackware-linux/bin/ld: skipping incompatible /usr/lib/libpthread.so when searching for -lpthread

Is there a way to make --link-flags "-L/usr/lib64" default for crystal build and similar commands?

[1] See also rust-lang/rust#14663

[ysbaddaden]

1. this is a LLVM issue, whatever the compiler LLVM was built with, llvm-config --cxxflags shouldn't output incompatible options.

2. I believe we added -L/usr/lib and -L/usr/local/lib because they aren't by default FreeBSD (for some reason) and it seemed harmless, but it looks like some distributions do break expectations :(

[RX14]

for (1) I agree with @ysbaddaden

for (2) we should probably remove these hacks and implement these hacks in wrapper scripts in packaging efforts etc. Hardcoding hacks into the compiler is never a good idea. Crystal depends on a sane build environment. If it's not provided we should fail.

[next-mad-hatter]

1. I'd concur here; I'll also try and file a bug report at llvm bugzilla (couldn't find anything relatied there, waiting for registration for now); but since the incompatibility seems to be quite old (the rust issue is from 2014) I wouldn't necessarily expect a fix on the llvm side anytime soon. The question to me is what would constitute the most pragmatic solution for now. Building crystal with env CXX=clang works without problems here so just including this information somewhere might be one;
   for build to universally work with gcc sanitizing the output of llvm-config would probably be necessary.

2. I think I made a mistake there -- the prebuilt 64bit version does link correctly in the end, I must have overlooked the program output among the 'skipping incompatible' messages. While it's not pretty it does work, and while crystal prepends some directories to the system's library search path, those are posix after all. Still, a way of universally prepending library path for crystal to use would be nice -- something like aliasing crystal --link-flags won't work right now since the option is local to the build/run commands.

Looking forward to trying crystal then :)