error: relocation R_X86_64_TPOFF32 against hidden symbol `_ZN2v88internal18g_current_isolate_E' can not be used when making a shared object

[mplemay]

When upgrading to the latest version of the v8 create, I encounter the following error:

  = note: /usr/bin/ld: /tmp/rustcnxkAyd/libv8-fa1f4565c5216947.rlib(binding.o): relocation R_X86_64_TPOFF32 against hidden symbol `_ZN2v88internal18g_current_isolate_E' can not be used when making a shared object
          /usr/bin/ld: failed to set dynamic section sizes: bad value
          collect2: error: ld returned 1 exit status

despite the part of my code which references isolation being unchanged (see below)

        // let isolate_params = v8::CreateParams::default().heap_limits(0, 2000 * 1024 * 1024);
        let isolate = &mut v8::Isolate::new(Default::default());
        let handle_scope = &mut v8::HandleScope::new(isolate);
        let mut context = v8::Context::new(handle_scope, Default::default());
        let scope = &mut v8::ContextScope::new(handle_scope, context);

Do y'all have any pointers on how to debug/resolve this issue?

[zty012]

Downgrade v8 crate to 129.0.0

[piercefreeman]

@zty012 Do you have context on why this issue is present in 130.0.0 but not 129.0.0?

[bakjos]

I have a similar issue when updating from 130.0.7 to 134.4.0, relocation R_X86_64_TPOFF32 against v8::internal::g_current_local_heap_ cannot be used with -shared, not sure if V8 changed the flags used to compile the library

[devsnek]

It would be helpful to know more about how you are using this crate. Are you producing a shared library from rustc? What flags are you using? I haven't been able to trivially reproduce a non-pic binary.

[bakjos]

For me it only happens while compiling to linux, in mac works well, these are the linking flags "-Wl,--gc-sections" "-shared" "-Wl,-z,relro,-z,now" "-Wl,-O1" "-Wl,--strip-debug" "-nodefaultlibs" "-shared" "--target=x86_64-unknown-linux-gnu" "-no-canonical-prefixes" "-lm" "-fuse-ld=lld" "-Wl,--build-id=md5" "-Wl,--hash-style=gnu" "-Wl,-z,relro,-z,now" "-l:libc++.a" "-l:libc++abi.a"

[kylewlacy]

I hit this error as well: I've been trying to speed up incremental compilation times in my project (basically trying to emulate Bevy's dynamic linking trick, although I haven't quite cracked the code yet). I was able to reproduce this error in this example repo (bump the v8 version up to v136.0.0 to reproduce the error)

I started digging into this error, and I tracked it down to this commit in V8: https://github.com/v8/v8/commit/36c814a6bacc3a16d123f9e4f336319d2453d574

Basically, V8 recently changed how thread-local variables are handled, and the new way doesn't work when dynamic linking (something about symbol visibility maybe?). Or rather, specific settings need to be set during the build so V8 compiles thread-locals in a way that's compatible with dynamic linking. Locally, I validated that patching this section to forcefully define V8_TLS_LIBRARY_MODE as 1 fixes the linker error. I also noticed that they recently updated the Ninja build to change this setting more easily: https://github.com/v8/v8/commit/2576961068cf38ecd94fc708c8746d1020cbc359

[bakjos]

@devsnek I can confirm that patching the build to set V8_TLS_LIBRARY_MODE to 1 fixed my issue as well

[guillaumebort]

You can build with these args v8_monolithic=true v8_monolithic_for_shared_library=true