This is the Makefile analog of r247833, except that the test also had to be changed such that clang actually attempts to link the program as opposed to just building it. Because of that change, I also switched the order to checking for ld/clang architecture support, because now lack of ld support would make the clang check fail. This fixes PR24776.
Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
LGTM.
Thanks for working this up.
Side question: Is there a reason you are still using autoconf? With any luck we'll be deprecating the autoconf build system in the next few months, if there are reasons you can't use CMake I would like to help address those.
Thanks,
-Chris
Thanks for the quick review. To answer your side question, last time I checked I ran into https://llvm.org/bugs/show_bug.cgi?id=24157. However, I can't say that once that's fixed we'll be able to switch, because I haven't done any sort of testing beyond trying it on my local machine. Also we're currently officially still on LLVM 3.3 due to performance regression caused by the JIT->MCJIT transition and while we're slowly working through these, it's just easier to have the build system code be uniform between the two and autoconf worked in all versions since 3.3 for us.
This change introduced a regression. The compiler compiles successfully but now fails to link because the platform arguments are not passed. The linker now errs out because it thinks it is mixing platforms.
What exactly is failing? Is there a simple patch (sounds like you think we
may have to pass additional arguments?). Can you put together a patch?
Jeremy,
While this is a regression that should be investigated, I'm going to ask the question I ask anyone when the report issues related to autoconf. Is there a reason you're not using CMake? We are working to deprecate the autoconf build system, so the intention is that it will be going away.
Thanks,
-Chris