-
Notifications
You must be signed in to change notification settings - Fork 961
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 build fails with "error: invalid conversion from const void*
to void*
"
#145
Comments
invalid conversion...
const void*
to void*
"
Thank you for the report. Which Linux distribution do you use? So we can try to reproduce this. |
Do you use Alpine Linux? If so, then I believe we will have to apply this or this patch to our LLVM version to get the build working. The reason is that Alpine Linux is based on musl libc instead of GNU libc, and the LLVM version that we use does not contain the patches needed to compile on musl libc (details). |
The first patch actually doesn't change anything at all. It just causes the compiler to take the ELSE case but the ELSE case contains exactly the same macros as the IF case, except that it verifies first that no macro of that name exist (which isn't the case and which had nothing to do with the reported problem). So I have no idea what the first patch is supposed to fix. The 2nd one will of course work and is the same thing I already added by hand. If this is caused by musl, then I'll take the issue there. I just checked the standards again. The C standard says that "stdX" is a pointer to a FILE object, it doesn't say anything about being a const pointer. And the POSIX standard explicitly provides Now it fails at a different location because of duplicate symbols. |
glibc follows the gcc stanards though, and stdout is a #define in their library. #defines are const propagated by the language standard and wouldn't display the behavior of a pointer. I messed around with what the return type of that EXPLICIT_FUNCTION macro should be in ToT and came up with. ptrs.cpp:12:18: warning: address of stack memory associated with local variable 'stdNonsense' returned The C++11 and 17 standards both agree that const void* -> void* conversions and other const conversions of the sort violate the purpose of the keyword and technically doing is also breaking the standard, as is taking a reference to a const pointer in general since all of those things allow modification where there should be any. C++17 allows it under the situation where the converted value is a temporary and can't be modified, but otherwise there's a reason const_cast<> exists. So GCC doesn't allow this, Clang hasn't since it supported C++11, and Visual Studio's CL doesn't accept it.
I'd take that as a sign that the library needs to be updated rather than the compiler, but that's just me. I'm not sure how integral muscl libc is to Alpine since I've never seen it mentioned until this thread, but I thought I'd run some tests for you. Did you try -fpermissive to disable the error? |
@CodingMarkus What Linux distribution do you use? I would like to reproduce the issue before trying to fix it. |
…musl libc. This commit applies the following two upstream patches: * https://reviews.llvm.org/D33883 * https://git.alpinelinux.org/cgit/aports/tree/main/llvm5/dynamiclibrary-fix-build-musl.patch?id=HEAD For more details, see avast/retdec#145
Since we have not received an answer from you and we are unable to reproduce the issue, I have decided to apply both upstream patches (1, 2) to our LLVM fork (see avast/llvm@753e703). RetDec now uses LLVM with this commit for build (a0994e7). If there are more issues with the build, please submit a separate issue. I am closing this one as fixed as it deals with a specific error. |
It was no Linux distribution at all, it was a special Docker Container that is based upon Alpine Linux and I reported that issue to the musl dev team and they said LLVM's code operates outside the POSIX standard as well as outside the C11 standard and that's why it won't compile as musl is "brutally" optimized for size using any trick that is allowed without violating these two standards. And according to these standards STDIN/SDTOUT/STDERR are "expressions whose result is the stream" and they are not the streams themselves, thus no standard would guarantee |
When I try to build on Linux following the instructions given in the main README, it won't even compile.
GCC/G++ version 6.4
The text was updated successfully, but these errors were encountered: