[BUG] ld.lld.exe: error: zlib is not available

[personshelldon]

Description

NDK changelog is asking for people to start testing with LLD, but I can not compile my modules after this change (using LLD).

What I was done:

1. Modified CMakeLists.txt to use LLD.
2. I have another prebuilt (libsamba.so ) that I am linking into my lib
3. set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=lld")
4. Try to build project
5. Error

FAILED: ../../../../build/intermediates/cmake/debug/obj/x86_64/libsambawrapper.so 
  cmd.exe /C "cd . && C:\Users\don\AppData\Local\Android\sdk\ndk-bundle\toolchains\llvm\prebuilt\windows-x86_64\bin\clang++.exe --target=x86_64-none-linux-android21 --gcc-toolchain=C:/Users/don/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64 -fPIC --sysroot C:/Users/don/AppData/Local/Android/sdk/ndk-bundle/toolchains/llvm/prebuilt/windows-x86_64/sysroot -g -DANDROID -fdata-sections -ffunction-sections -funwind-tables -fstack-protector-strong -no-canonical-prefixes -fno-addrsig -Wa,--noexecstack -Wformat -Werror=format-security -stdlib=libc++ -std=c++1z -fPIC -pipe -Wall -Werror -Wno-macro-redefined -fstack-protector-all -D_FORTIFY_SOURCE=2 -D__USE_FILE_OFFSET64=1 -D_FILE_OFFSET_BITS=64 -fvisibility=hidden -g -funwind-tables -fno-omit-frame-pointer -O0 -fno-limit-debug-info  -Wl,--exclude-libs,libgcc.a -Wl,--exclude-libs,libatomic.a -static-libstdc++ -Wl,--build-id -Wl,--warn-shared-textrel -Wl,--fatal-warnings -Wl,--no-undefined -Qunused-arguments -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now  -fuse-ld=lld -shared -Wl,-soname,libsambawrapper.so -o ..\..\..\..\build\intermediates\cmake\debug\obj\x86_64\libsambawrapper.so CMakeFiles/sambawrapper.dir/src/main/jni/samba/samba_jni.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/SambaInputStream.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/SambaFile.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/SambaStat.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/BlockingBuffer.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/Chunk.cpp.o CMakeFiles/sambawrapper.dir/src/main/jni/samba/GlobalMutexes.cpp.o  -lc++_shared -llog ../../../../src/main/jni/smbclient/lib/x86_64/libsamba.so -latomic -lm && cd ."
  ld.lld.exe: error: zlib is not available
  ld.lld.exe: error: zlib is not available
  clang++.exe: error: linker command failed with exit code 1 (use -v to see invocation)
  ninja: build stopped: subcommand failed.

If I'm not using -fuse-ld=lld - everything works

Environment Details

Android Studio 3.3
NDK r19
Windows 10

[DanAlbert]

@stephenhines I don't see a libz.dll anywhere in the toolchain prebuilts. Is this something you want to statically link?

[personshelldon]

No, there is no any place where I try to link libz manually. But there is a fact - if I enable LLD there is an error, without LLD NDK r18 and r19 work and build everything correctly. Maybe, libz is missing in NDK r19 and not in r18?

[DanAlbert]

If I'm not mistaken the error here is that lld itself depends on libz. That's true of the binaries I have on Linux, but the typical linux system has libz so that isn't a problem. I think this is just a dependency that needed to be shipped but wasn't.

[DanAlbert]

I've added a KI to the changelog, FWIW. Linux is better tested, and Darwin should work (I'll verify once I have a mac in front of me, but we are using it to build AOSP from Darwin; we just don't build AOSP from Windows so that is only covered by the NDK, and apparently inadequately so).

As much as I don't really want to double our test time, I'll get our test runner to build and run every test twice (once with the default linker and once with lld) for better coverage.

[stephenhines]

This may only be broken if you are linking something that has compressed sections. It is very likely that libsamba.so is doing that. In that case, the Decompressor in LLVM doesn't know how to unzip it. We're talking about how to build libz.dll even, since it is not provided by our build at all.

[DanAlbert]

My Linux lld is linked directly to libz. Is windows using it via dlopen?

[pirama-arumuga-nainar]

The libLLVMSupport library implements and exports zlib compression functionality. If libz is detected at build time, the library builds/links against it (which is the case in Linux). If libz is not detected, the library has stubs that always return false or throw an error (which is the case in our build of Windows). This surfaces to the user only if a functionality that requires libz is requested - in this case the ability to read compressed sections in DWARF (lib/DebugInfo/DWARF/DWARFContext.cpp).

[enh]

Ah, I did wonder about that custom-looking error message... That explains it.

[DanAlbert]

Ah, so this is something that only comes up when that feature is encountered then. That's much better than I'd feared.

I'm going to redo some Windows LLD testing (that is, run our test suite with LLD forced) just in case, but assuming that comes back fine I'll tone down the wording of the KI in the changelog.

[personshelldon]

Ok, is there any fix for now or I need to wait for the next version of the NDK?

[DanAlbert]

To use compressed symbols with LLD yes, you'll need an update.

You might be able to avoid the compressed symbols. Not sure if there's an easy way to tell where they're coming from. Presumably readelf, but I'm not sure what to look for.

[personshelldon]

Ok, thanks! I'll disable LLD for now.

[DanAlbert]

@pirama-arumuga-nainar says he's going to be looking in to this soon.

[personshelldon]

Append set(CMAKE_SYSROOT "${ANDROID_SYSROOT}") to the end of the file ${ANDROID_SDK_ROOT}/ndk-bundle/build/cmake/android.toolchain.cmake.

Does that help, @personshelldon ?

No, the same error

[sakrist]

I had similar. Try this:
-DCMAKE_SYSROOT=$NDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot

[personshelldon]

I had similar. Try this:
-DCMAKE_SYSROOT=$NDK/toolchains/llvm/prebuilt/windows-x86_64/sysroot

This is not working on Windows

[pirama-arumuga-nainar]

I just merged https://android-review.googlesource.com/q/topic:%22windows-clang-libz%22+(status:open%20OR%20status:merged). This will be part of an AOSP Clang toolchain soon but no idea which NDK release it'll be part of.

[DanAlbert]

It'll most likely be r20. It's a non-trivial update from what's currently in r19 so that could be quite disruptive.

[personshelldon]

I just merged https://android-review.googlesource.com/q/topic:%22windows-clang-libz%22+(status:open%20OR%20status:merged). This will be part of an AOSP Clang toolchain soon but no idea which NDK release it'll be part of.

I have recompiled NDK r19 with this patch and now there is no any zlib not found errors, but there is always freeze on the same task when building- Task :app:transformResourcesWithMergeJavaResForOthersDebug. I thinks it is compatibility error and I'll wait for the next NDK release, but this patch is the step on the right way.

[personshelldon]

Ok, I found the root cause of hang - it is LLD multithread. It is the same problem as this issue. After I set set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=lld -Wl,--no-threads") everething works as expected with LLD. The patch for zlib is working.

[DanAlbert]

Filed #897 to fix the defaults that we control and mark the KI, since that probably deserves a better callout than a bug report most people won't see.

[Tolriq]

Seems this issue is still present in R20?
lld seems to work to generate ARMs .so but fails for the x86 x86_64 ones.

ld.lld: error: D:/Android/sdk/ndk-bundle/build//../toolchains/llvm/prebuilt/windows-x86_64/bin/../lib/gcc/i686-linux-android/4.9.x\libgcc_real.a(unwind-dw2.o): contains a compressed section, but zlib is not available
ld.lld: error: D:/Android/sdk/ndk-bundle/build//../toolchains/llvm/prebuilt/windows-x86_64/bin/../lib/gcc/x86_64-linux-android/4.9.x\libgcc_real.a(unwind-dw2-fde-dip.o): contains a compressed section, but zlib is not available

As a side note the ARM v8 .so when linked via lld have nearly doubled size
Bin 235760 -> 407848 bytes probably because I had to remove --gc-sections as unsuported?

Is this a known/documented issue or should I open a new one?

[enh]

--gc-sections isn't "unsupported" --- we use it in the Android build itself :-) do you mean you're hitting #927? if not, please file a new --gc-sections bug with details about what's not working for you.

(i can't answer the "is the new lld in r20?" question, so someone else will have to address that...)

[Tolriq]

Ok so I must admit I'm not a master at all at NDK build chain and adding a space after the comma in the Android.mk generated the issue.

With --gc-sections the .so is still way bigger Bin 235760 -> 342280 bytes but less then than without

But in all cases without Windows support can't use in release build for now.

[enh]

try https://github.com/google/bloaty to see what the differences are? (or just readelf as a quick first pass if you've only got one .so.)

[Tolriq]

Don't have a linux machine nearby, since it seems not known / wanted, will look into that tool and make proper report in the next couple of weeks. Anything else I should prepare for that report?

[DanAlbert]

The toolchain that is in r20 came from about a week before the fix was merged. The fix is in r21.

[DanAlbert]

@Tolriq as for the size issue, I assume by armv8 you mean arm64? If so, that's probably fixed by https://reviews.llvm.org/D55029, which is also too old for r20 but is in r21. Try the canary build if you want to be sure.

[Tolriq]

Thanks @DanAlbert tested last canary 5641003 and can confirm both issues are fixed.

[enh]

@Tolriq thanks for confirming!