-
Notifications
You must be signed in to change notification settings - Fork 264
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
Clang 3.8 from NDK r11c for Windows x86_64 can't correctly determine the linker's executable name #75
Comments
Speaking of backward-compatibility: |
clang 3.8 from NDK r11c for Windows x86 does not accept both variants: |
I believe this is fixed in the r12 beta. |
@stephenhines That would be great, because with NDK r11c for Windows x86 you can't link the binaries by using the compiler driver - even g++ incorrectly handles the '-fuse-ld=' switch, see #76 for the details |
The beta is out, btw: https://github.com/android-ndk/ndk/wiki#current-beta-release. Give it a shot and let us know (I'd check myself, but no Windows machine handy atm). You might want to subscribe to https://groups.google.com/forum/#!forum/android-ndk-announce |
@stephenhines if this isn't already fixed, do you think it's something you can get fixed for r12 (June)? |
@DanAlbert Thank you, Dan - I'll check r12 beta for Windows x86 and x86_64 ASAP |
If this doesn't work for r12 beta, it won't work for r12. This is not something we are going to update for. Sorry. |
@DanAlbert @stephenhines
And here's the info on the wiki page:
|
@stephenhines I wasn't thinking a full fledged update, but a cherry-pick. @dosvidos, two of your earlier comments:
The acceptance of |
Ugh. There was an emergency update of the NDK late yesterday because a piece of metadata was breaking every Android Studio install. The NDK got updated, but no one sent me the new SHAs/sizes. I'll go hassle someone and get that fixed. |
@DanAlbert Oh, my - nice catch, Dan! This is Windows x86_64 NDK
And this is Windows x86 NDK
So |
Over to me for the packaging issue... At the very least we can make sure that's fixed by beta 2. |
Oohhhhh actually I misunderstood. You mean the 32-bit NDK, whereas I thought we meant x86 Android. That's actually somewhere between a known issue and working as intended. Gold can't be built with the mingw for 32-bit windows. This is noted in the changelog for r11: https://github.com/android-ndk/ndk/wiki/Changelog-r11#binutils I can check if the updated gold doesn't have the same problem as the old one, but if it's still a problem it's unlikely that the 32-bit NDK will ever get fixed (fixing mingw isn't something we have the resources to do). |
@DanAlbert Oh, I see - so that's the intentional decision and also a breaking difference from |
(SHAs and sizes are fixed now) Less of an intentional decision and more of a decision that was made for us by our tools. We'd ship it if we had it, but given that it's already in the 64-bit NDK (the 32-bit NDK should be considered legacy) fixing mingw to be able to build gold isn't a priority. |
It wasn't fixed in Clang shipped in NDK r12
It complains on '-fuse-ld=gold' with the same error
As a workaround I'm forced to use '-fuse-ld=gold.exe' and '-fuse-ld=bfd.exe' |
How often will Clang be updated to new major version? 3.9 then 4.0? |
This was fixed for all but the 32-bit Windows NDK, for which we don't plan to update gold (because it isn't possible to build with mingw currently). I am going to close this out, but if there is indeed a lot of pressure to ship a 32-bit gold just for LTO, feel free to comment/reopen, and we can reevaluate the options. |
This wasn't fixed. It's not a gold issue, it's that Clang still doesn't handle |
I noticed an LLVM patch in review for fixing this: https://reviews.llvm.org/D43621. It switches to the |
This got submitted upstream. @stephenhines: I suspect we don't need an explicit cherry-pick of this since we'll probably have yet another clang update before we pick one for r18, but just FYI. |
This looks fixed in the r18 canary Windows clang.
The fix was merged to LLVM as r326164. There's an LLVM regression test for it. |
Our build system is using Clang not only as the compiler, but also as the front-end driver for a linker back-end. Unfortunately, Clang 3.8 from NDK r11c can't properly determine the linker executable:
leads to an error
clang++.exe : error : invalid linker name in argument '-fuse-ld=gold'
Same story goes for
-fuse-ld=bfd
. If I append the.exe
extension to the linker name the Clang is able to invoke the right executable and link the binary.That's inconvenient, and it's the behavioral difference from Clang 3.5/6 shipped in NDK r10e.
@DanAlbert has mentioned that your team has fixed this problem before - so this could be a regression.
The text was updated successfully, but these errors were encountered: