Clang 3.8 from NDK r11c for Windows x86_64 can't correctly determine the linker's executable name

[dosvidos]

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:

android-ndk-r11c\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe Debug/main.o Debug/android_native_app_glue.o
-gcc-toolchain android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64
-target armv7-none-linux-androideabi
-Wl,-soname,libAndroid5.so
-shared
--sysroot=android-ndk-r11c/platforms/android-9/arch-arm
-Wl,-rpath-link=android-ndk-r11c/platforms/android-9/arch-arm/usr/lib "-landroid" "-lEGL" "-lGLESv1_CM"
-fuse-ld=gold
-Wl,--no-undefined
-Wl,-z,noexecstack
-Wl,-z,relro
-Wl,-z,now
-L"android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
-L"android-ndk-r11c/platforms/android-9/arch-arm/usr/lib"
-L"android-ndk-r11c/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a"
-L"android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/lib/gcc/arm-linux-androideabi/4.9/armv7-a"
"android-ndk-r11c/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/libgnustl_static.a"
-lc
-lm
-llog
-lgcc
-olibAndroid5.so

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.

[dosvidos]

Speaking of backward-compatibility:
In case of NDK r10e x86_64 for Windows
clang 3.6 accepts both formats: -fuse-ld=gold AND -fuse-ld=gold.exe
clang 3.5 refuses -fuse-ld=gold.exe as unknown option.
And clang 3.8 only accepts -fuse-ld=gold.exe

[dosvidos]

clang 3.8 from NDK r11c for Windows x86 does not accept both variants:
clang++.exe: error: invalid linker name in argument '-fuse-ld=gold'
clang++.exe: error: invalid linker name in argument '-fuse-ld=gold.exe'

[stephenhines]

I believe this is fixed in the r12 beta.

[dosvidos]

@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

[DanAlbert]

The beta is out, btw: https:/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

[DanAlbert]

@stephenhines if this isn't already fixed, do you think it's something you can get fixed for r12 (June)?

[dosvidos]

@DanAlbert Thank you, Dan - I'll check r12 beta for Windows x86 and x86_64 ASAP

[stephenhines]

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.

[dosvidos]

@DanAlbert @stephenhines
Guys, I've downloaded the r12 beta archives for Windows using the wiki links, but neither the file sizes nor the SHA1 check-sums does match the ones published on a wiki page. Could you have a look?
Here's what I've got:

$ openssl dgst -sha1 android-ndk-r12_.zip
SHA1(android-ndk-r12-beta1-windows-x86.zip)= 840d2f3929ad91898b4b44e94657406bec39a410
SHA1(android-ndk-r12-beta1-windows-x86_64.zip)= 247e48b9903f3ea1b9fc4b0cadef7821e7f312f1
$ ls -l android-ndk-r12_.zip
698425840 Apr 14 21:14 android-ndk-r12-beta1-windows-x86.zip
741437055 Apr 14 21:14 android-ndk-r12-beta1-windows-x86_64.zip

And here's the info on the wiki page:

Windows 32-bit android-ndk-r12-beta1-windows-x86.zip 698416170 6864c3097c3f81d43067649fad88601c4b555f21
Windows 64-bit android-ndk-r12-beta1-windows-x86_64.zip 741437610 e272fa956d7df3447f77a2edc165e25793582273

[DanAlbert]

@stephenhines I wasn't thinking a full fledged update, but a cherry-pick.

@dosvidos, two of your earlier comments:

Speaking of backward-compatibility:
In case of NDK r10e x86_64 for Windows
clang 3.6 accepts both formats: -fuse-ld=gold AND -fuse-ld=gold.exe
clang 3.5 refuses -fuse-ld=gold.exe as unknown option.
And clang 3.8 only accepts -fuse-ld=gold.exe

clang 3.8 from NDK r11c for Windows x86 does not accept both variants:
clang++.exe: error: invalid linker name in argument '-fuse-ld=gold'
clang++.exe: error: invalid linker name in argument '-fuse-ld=gold.exe'

The acceptance of -fuse-ld=gold.exe varies between x86 and x86_64? That's surprising. There is an ld.gold.exe in both directories, right?

[DanAlbert]

Guys, I've downloaded the r12 beta archives for Windows using the wiki links, but neither the file sizes nor the SHA1 check-sums does match the ones published on a wiki page. Could you have a look?

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.

[dosvidos]

@DanAlbert Oh, my - nice catch, Dan!

This is Windows x86_64 NDK

$ find /f/work/android-ndk-r11c/toolchains -type f -name ld*.exe
/f/work/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/aarch64-linux-android/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/aarch64-linux-android/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/windows-x86_64/aarch64-linux-android/bin/ld.gold.exe
/f/work/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/arm-linux-androideabi/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/arm-linux-androideabi/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/arm-linux-androideabi/bin/ld.gold.exe
/f/work/android-ndk-r11c/toolchains/mips64el-linux-android-4.9/prebuilt/windows-x86_64/mips64el-linux-android/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/mips64el-linux-android-4.9/prebuilt/windows-x86_64/mips64el-linux-android/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/mipsel-linux-android-4.9/prebuilt/windows-x86_64/mipsel-linux-android/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/mipsel-linux-android-4.9/prebuilt/windows-x86_64/mipsel-linux-android/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/x86-4.9/prebuilt/windows-x86_64/i686-linux-android/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/x86-4.9/prebuilt/windows-x86_64/i686-linux-android/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/x86-4.9/prebuilt/windows-x86_64/i686-linux-android/bin/ld.gold.exe
/f/work/android-ndk-r11c/toolchains/x86_64-4.9/prebuilt/windows-x86_64/x86_64-linux-android/bin/ld.bfd.exe
/f/work/android-ndk-r11c/toolchains/x86_64-4.9/prebuilt/windows-x86_64/x86_64-linux-android/bin/ld.exe
/f/work/android-ndk-r11c/toolchains/x86_64-4.9/prebuilt/windows-x86_64/x86_64-linux-android/bin/ld.gold.exe

And this is Windows x86 NDK

$ find /f/wrk/android-ndk-r11c/toolchains -type f -name ld*.exe
/f/wrk/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/windows/aarch64-linux-android/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/aarch64-linux-android-4.9/prebuilt/windows/aarch64-linux-android/bin/ld.exe
/f/wrk/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/arm-linux-androideabi-4.9/prebuilt/windows/arm-linux-androideabi/bin/ld.exe
/f/wrk/android-ndk-r11c/toolchains/mips64el-linux-android-4.9/prebuilt/windows/mips64el-linux-android/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/mips64el-linux-android-4.9/prebuilt/windows/mips64el-linux-android/bin/ld.exe
/f/wrk/android-ndk-r11c/toolchains/mipsel-linux-android-4.9/prebuilt/windows/mipsel-linux-android/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/mipsel-linux-android-4.9/prebuilt/windows/mipsel-linux-android/bin/ld.exe
/f/wrk/android-ndk-r11c/toolchains/x86-4.9/prebuilt/windows/i686-linux-android/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/x86-4.9/prebuilt/windows/i686-linux-android/bin/ld.exe
/f/wrk/android-ndk-r11c/toolchains/x86_64-4.9/prebuilt/windows/x86_64-linux-android/bin/ld.bfd.exe
/f/wrk/android-ndk-r11c/toolchains/x86_64-4.9/prebuilt/windows/x86_64-linux-android/bin/ld.exe

So ld.gold.exe is missing from NDK r11c for Windows x86

[DanAlbert]

Over to me for the packaging issue... At the very least we can make sure that's fixed by beta 2.

[DanAlbert]

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:/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).

[dosvidos]

@DanAlbert Oh, I see - so that's the intentional decision and also a breaking difference from r10e.

[DanAlbert]

(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.

[nvidiamfilimonov]

It wasn't fixed in Clang shipped in NDK r12

android-ndk-r12\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe" --version
Android clang version 3.8.256229 (based on LLVM 3.8.256229)
Target: x86_64-unknown-linux
Thread model: posix
InstalledDir: f:\work\android-ndk-r12\toolchains\llvm\prebuilt\windows-x86_64\bin

It complains on '-fuse-ld=gold' with the same error

clang++.exe: error: invalid linker name in argument '-fuse-ld=gold'

As a workaround I'm forced to use '-fuse-ld=gold.exe' and '-fuse-ld=bfd.exe'

[Zingam]

How often will Clang be updated to new major version? 3.9 then 4.0?

[stephenhines]

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.

[DanAlbert]

This wasn't fixed. It's not a gold issue, it's that Clang still doesn't handle -fuse-ld=gold correctly on Windows.

[rprichard]

I noticed an LLVM patch in review for fixing this: https://reviews.llvm.org/D43621. It switches to the can_execute function. It looks like the patch would allow an -fuse-ld=gold argument if either gold or gold.exe existed on Windows.

[DanAlbert]

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.

[rprichard]

This looks fixed in the r18 canary Windows clang.

C:\src\mess>c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin\clang hello.cpp -fuse-ld=bfd

C:\src\mess>c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin\clang hello.cpp -fuse-ld=gold

C:\src\mess>c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin\clang hello.cpp -fuse-ld=bfd.exe

C:\src\mess>c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin\clang hello.cpp -fuse-ld=gold.exe

C:\src\mess>c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin\clang --version
Android (4751641 based on r328903) clang version 7.0.2 (https://android.googlesource.com/toolchain/clang 003100370607242ddd5815e4a043907ea9004281) (https://android.googlesource.com/toolchain/llvm 1d739ffb0366421d383e04ff80ec2ee591315116) (based on LLVM 7.0.2svn)
Target: armv7a-none-linux-android16
Thread model: posix
InstalledDir: c:\src\android-ndk-r18-canary-4855205-stand-arm-16\bin

The fix was merged to LLVM as r326164. There's an LLVM regression test for it.