New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
llvm 3.9: Download and build Polly #20941
Conversation
@spacekitteh, thanks for your PR! By analyzing the history of the files in this pull request, we identified @gebner, @vcunat and @acowley to be potential reviewers. |
Well, nox-review is going to take forever to check and build... |
I think this should probably have the mass-rebuild tag |
Well, it looks like the travis instances don't have enough RAM to build it. |
So, I get this error: CMakeFiles/clang.dir/cc1_main.cpp.o:
In function `cc1_main(llvm::ArrayRef<char const*>, char const*, void*)': cc1_main.cpp:
(.text._Z8cc1_mainN4llvm8ArrayRefIPKcEES2_Pv+0x35b): undefined reference to `polly::initializePollyPasses(llvm::PassRegistry&)'
collect2: error: ld returned 1 exit status From what it appears, polly appears to be built in llvm.nix, but then it doesn't appear to be passed onto clang.nix? I think clang may need to be patched to link the previously-created-in-llvm.nix polly.so that lives in the nix store, to avoid having to build polly a second time. |
If I can't figure out how to appropriately patch the CMakeLists.txt, I don't think I can get around building polly twice: once in llvm.nix, and again in clang.nix. I think this might be an example of the perfect use-case of multiple build outputs. Polly has to be in the llvm/tools/polly dir upon building clang in order to statically link it, unless the cmake file is patched. |
@@ -26,7 +28,7 @@ let | |||
|
|||
postPatch = '' | |||
sed -i -e 's/Args.hasArg(options::OPT_nostdlibinc)/true/' lib/Driver/Tools.cpp | |||
sed -i -e 's/DriverArgs.hasArg(options::OPT_nostdlibinc)/true/' lib/Driver/ToolChains.cpp | |||
sed -i -e 's/DriverArgs.hasArg(options::OPT_nostdlibinc)/true/' lib/Driver/ToolChains.cpp |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
whitespace!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
death to whitespace
@shlevy has also worked a fair amount on LLVM, if I remember correctly |
So, I currently get the following error when using clang: Possibly related: https://llvm.org/bugs/show_bug.cgi?id=22952 It might be because it's linking against a .so instead of a .a? |
It looks like LLVM_BUILD_LLVM_DYLIB is broken, actually. I don't seem to have a libLLVM.so in my build output. |
Could it be to do with having two separate builds? |
] ++ | ||
# (stdenv.lib.optional llvm.enableSharedLibraries "-DLLVM_LINK_LLVM_DYLIB:Bool=true") ++ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how can i do this? That is, how to reference the input argument to a build dependency?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
eh, doesn't matter anyway. it doesn't fix the problem.
There's this message, too, from clang build: WARNING: substitution variables should be valid bash names,
"ccLDFlags+" isn't and therefore was skipped;
it might be caused by multi-line phases in variables - see #14907 for details. |
I think it's a problem in this bit of code. It thinks that in cc-wrapper |
289b454
to
ddb1321
Compare
Damn, ddb13213531a539e616deb71afb915fe97f9ba22 didn't fix it. Anyone have any ideas? It probably helped with something, though, as I no longer got those #14907 messages. |
056d7e5
to
9e9f8cc
Compare
By the way, did the problems motivating 31bdc2f ever get reported/fixed in Nixpkgs master? Also--what's the status of this? Are there outstanding problems with this |
I don't think it's been fixed, and I've never seen that problem causing anything more than warnings. |
This needs to be rewritten for newer llvm expressions |
Motivation for this change
#20890
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandbox
innix.conf
on non-NixOS)
nix-shell -p nox --run "nox-review wip"
./result/bin/
)