Android link error: relocation R_ARM_TLS_LE32 against tl.foo cannot be used with -shared

[tuket]

Zig Version

0.12.0-dev.983+78f2ae7f2

Steps to Reproduce and Observed Behavior

Take this program:

// tl.zig
const std = @import("std");

threadlocal var foo: std.Thread.Id = 0;

export fn setFoo() void {
    foo = std.Thread.getCurrentId();
}

export fn getFoo() std.Thread.Id {
    return foo;
}

We can build a shared lib for linux with the following command:

zig.exe build-lib -target arm-linux -dynamic -fPIC tl.zig

The previous command compiles fine.

Now if we change arm-linux to arm-linux-android:

zig.exe build-lib -target arm-linux-android -dynamic -fPIC tl.zig

We get the following compile error:

error: ld.lld: relocation R_ARM_TLS_LE32 against tl.foo cannot be used with -shared
    note: defined in libtl.so.o
    note: referenced by tl.zig:0
    note:               libtl.so.o:(setFoo)
error: ld.lld: relocation R_ARM_TLS_LE32 against tl.foo cannot be used with -shared
    note: defined in libtl.so.o
    note: referenced by tl.zig:0
    note:               libtl.so.o:(getFoo)
error: ld.lld: relocation R_ARM_TLS_LE32 against Thread.LinuxThreadImpl.tls_thread_id cannot be used with -shared
    note: defined in libtl.so.o
    note: referenced by Thread.zig:0 (C:\Users\tuket\Documents\APPS\zig_experimental\lib\std/Thread.zig:0)
    note:               libtl.so.o:(Thread.LinuxThreadImpl.getCurrentId)
error: ld.lld: relocation R_ARM_TLS_LE32 against debug.panic_stage cannot be used with -shared
    note: defined in libtl.so.o
    note: referenced by debug.zig:0 (C:\Users\tuket\Documents\APPS\zig_experimental\lib\std/debug.zig:0)
    note:               libtl.so.o:(debug.panicImpl)

However, if we run the same command with zig 0.11.0, it compiles fine.

Expected Behavior

I'm not certain what should be the expected behavior, but it's weird that it used to work and now it doesn't.

This is preventing me from compiling Android apps.

For this bud report, I tried to make the program as simple as possible.

In my more elaborate Android program, I wasn't actually using the std.Thread.getCurrentId() function. In fact, when I would add the "-Drelease" flag to zig, the compiler error would go away (probably due to unused code elimination).

[tuket]

I think I found something interesting here.

Right. -fpie/-fPIE compiled object files cannot be linked in -shared mode.

As far as I know, for shared libraries I need the PIC (position independent code) flag but not the PIE (position independent executable) flag.

So I tried to to use -fno-PIE to make sure PIE is not used.

$ zig build-lib -target arm-linux-android -dynamic -fPIC -fno-PIE tl.zig

And I get this error:

error: unable to create compilation: TargetRequiresPIE

Could it be that zig is unnecessarily forcing PIE?

[tuket]

Found this:

pub fn requiresPIE(target: std.Target) bool {
    return target.isAndroid() or target.isDarwin() or target.os.tag == .openbsd;
}

Why does Android require PIE?

According to this, PIE shouldn't be used for dynamic libraries. Is this a mistake? I think we should require PIC for Android instead of PIE, isn't it?

[rootbeer]

I believe forcing PIC or PIE need to depend on what the output object is? I can see for a platform like Android that all executables must be PIE and shared libraries must be PIC. But from what I can tell (e.g., see https://mropert.github.io/2018/02/02/pic_pie_sanitizers/ and the pic/PIC/pie/PIE options in https://gcc.gnu.org/onlinedocs/gcc-7.2.0/gcc/Code-Gen-Options.html#Code-Gen-Options) PIE is only meant to be used when doing the final linking of an executable (or a static library meant to be part of an executable?). None of the doc I can find explicitly talks about why putting on PIE on a shared object is bad (one would think it harmless), but it seems to mess something up...

Rust has a relocation-model option which lays out the different combinations of choices in a more sane and complete way: https://doc.rust-lang.org/rustc/codegen-options/index.html#relocation-model (be sure to scroll down to the "Linking Effects" doc) Again, doesn't say why PIE on shared objects is bad, but does imply that.

[tuket]

I can see for a platform like Android that all executables must be PIE and shared libraries must be PIC

Android executables don't exist AFAIK? Android applications are Java based, and native code is always contained in a dynamic libraries, AFAIK.

Thanks for the links, the are quite interesting.

[mikdusan]

We have logic when setting ld.lld flags to only use pie when producing an executable. This patch adds the corresponding logic to llvm backend.

Can you try this patch?

diff --git a/src/codegen/llvm.zig b/src/codegen/llvm.zig
index cddd4340d..ea9be5c29 100644
--- a/src/codegen/llvm.zig
+++ b/src/codegen/llvm.zig
@@ -971,7 +971,7 @@ pub const Object = struct {
             builder.llvm.module.?.setModuleDataLayout(target_data);
 
             if (options.pic) builder.llvm.module.?.setModulePICLevel();
-            if (options.pie) builder.llvm.module.?.setModulePIELevel();
+            if (options.pie and options.effectiveOutputMode() == .Exe) builder.llvm.module.?.setModulePIELevel();
             if (code_model != .Default) builder.llvm.module.?.setModuleCodeModel(code_model);
 
             if (options.opt_bisect_limit >= 0) {

[tuket]

@mikdusan Yes, that fixes the error. Cheers!