fix build on Alpine Linux #351
Conversation
- make sure libexecinfo gets linked into compiler-rt when building against musl c library on Alpine Linux
|
This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM. |
|
@DoDoENT is this still a thing? |
|
@stefson, I haven't tried building on Alpine for a while. The last time I tried, it failed without the patch in this PR. After it got rejected here, I didn't go through the whole LLVM review process on the Phabricator - it was just too much PITA for something as exotic as this. |
|
@DoDoENT the llvm team now accepts pullrequest through this github repo, so maybe you want to try to resubmit the changes? I'm working with musl based gentoo, so I'm happy to see fixes (even though I haven't hit the underlying problem yet) |
|
@stefson, I'm no longer using Alpine Linux for my work (we started using Amazon Linux as our base image for most compatibility) so this is no longer relevant for me. However, feel free to take this patch and resubmit it as your own PR. It's really not a big deal 😄 If the build works for you without this fix, this is also great news. WIthout linking |
|
@DoDoENT I may try to resubmit. Could you give an example though for a binary that links against compiler-rt, so that I can try to reproduce this? I can't think of any at the moment. |
|
@stefson, I believe the error was during linking of |
|
that lib is part of compiler-rt-sanitizers, right? |
|
Yeah, it contains runtime support for the Address Sanitizer. |
The next step for inline assembly. Sorry, maybe it looks too big on the first glance. And it's kind of hard to extract something well-grained from the code and introduce it as a separate PR, but I try. Actually there is nothing really interesting done here, and the next will (I hope :) ) simplify your review process. 1) In this PR we introduce operand's constraints and the task is to collect them (and maybe transform a little) 2) There are two big functions copy-pasted from the traditional `Codegen` and I doubt they need to be reviewed. 3) We still don't do anything CIR-specific. Basically, we just work with strings in the same way like traditional `Codegen` does. 4) We just iterate over the input and output operands and collect the constraints 5) We still follow to the traditional `CodeGen` and don't do anything new, except a separate function that collects constraints infos in the very beginning of the `buildStmt`. Also, I renamed `AsmDialect` to `AsmFlavor` as you asked in llvm#326
The next step for inline assembly. Sorry, maybe it looks too big on the first glance. And it's kind of hard to extract something well-grained from the code and introduce it as a separate PR, but I try. Actually there is nothing really interesting done here, and the next will (I hope :) ) simplify your review process. 1) In this PR we introduce operand's constraints and the task is to collect them (and maybe transform a little) 2) There are two big functions copy-pasted from the traditional `Codegen` and I doubt they need to be reviewed. 3) We still don't do anything CIR-specific. Basically, we just work with strings in the same way like traditional `Codegen` does. 4) We just iterate over the input and output operands and collect the constraints 5) We still follow to the traditional `CodeGen` and don't do anything new, except a separate function that collects constraints infos in the very beginning of the `buildStmt`. Also, I renamed `AsmDialect` to `AsmFlavor` as you asked in llvm#326
The next step for inline assembly. Sorry, maybe it looks too big on the first glance. And it's kind of hard to extract something well-grained from the code and introduce it as a separate PR, but I try. Actually there is nothing really interesting done here, and the next will (I hope :) ) simplify your review process. 1) In this PR we introduce operand's constraints and the task is to collect them (and maybe transform a little) 2) There are two big functions copy-pasted from the traditional `Codegen` and I doubt they need to be reviewed. 3) We still don't do anything CIR-specific. Basically, we just work with strings in the same way like traditional `Codegen` does. 4) We just iterate over the input and output operands and collect the constraints 5) We still follow to the traditional `CodeGen` and don't do anything new, except a separate function that collects constraints infos in the very beginning of the `buildStmt`. Also, I renamed `AsmDialect` to `AsmFlavor` as you asked in llvm#326
against musl c library on Alpine Linux