Currently, lot's of test_darwin specs have been failing because they can't find file 'c/dlfcn'. This seems to be the first file from lib_c/*/ included from prelude through exception.cr and callstack.cr.
Example spec log: https://circleci.com/gh/crystal-lang/crystal/19443
Oddly enough this is only an issue in test_darwin jobs on pull requests, the nightly jobs don't fail.
My first thought was that somehow #7479 broke the default target, even though it shouldn't affect darwin at all. But these failures date back before it was merged, so that can't be the culprit.
bin/crystal --version prints default target x86_64-apple-macosx, but the folder name is src/lib_c/x86_64-macosx-darwin. I tried adding a symlink but that doesn't help. I think there is some renaming in place which should make them equivalent (?).
The oldest failure I could find was https://circleci.com/gh/crystal-lang/crystal/19431 on 2019-03-06 on commit https://github.com/crystal-lang/crystal/commit/adc42fa93a3ea7624b1e9ae1f0f0c2ddff985ff8
All builds (even previous ones which don't have this failure) are run with the latest release build Crystal 0.27.2 (2019-02-05).
the folder is just x86_64-darwin since https://github.com/crystal-lang/crystal/pull/7282
the old symlinks can probably be removed now that a new compiler has been released
Ah right. And x86_64-darwin doesn't exist if the branch is based on a commit before #7282 was merged. Why didn't I see that 馃檲
Failing PRs simply need to be rebased on master. :+1:
@RX14 Is there a specific reason why the folder is x86_64-darwin but crystal --version prints default target x86_64-apple-macosx. Shouldn't that better match up?
Also we could consider improving the error message. When requiring a file starting with c/ fails, the compiler could print the codegen target as in https://github.com/crystal-lang/crystal/blob/master/src/compiler/crystal/crystal_path.cr#L21