Managed to resolve it by compiling V8 statically into my app, and removing symbols from it using the "Exported symbols file" option. (using strip or objcopy on the already linked app didnt work)
2019. november 29., péntek 17:21:39 UTC+1 időpontban Zoltan B a következőt írta: > > Hi! I exported symbols from Electron and my built V8, and indeed the > symbols are the same e.g.: > > in Electron: > 00000000017a31f0 T __ZN2v86Object16SetInternalFieldEiNS_5LocalINS_5ValueEEE > > in V8 > 00000000000267f0 T __ZN2v86Object16SetInternalFieldEiNS_5LocalINS_5ValueEEE > > Is there a way to prefix my V8 somehow in the buildconfig to avoid these > namespace clashes? > > 2019. november 27., szerda 17:01:20 UTC+1 időpontban Zoltan B a következőt > írta: >> >> Thanks for your reply! No, I'm not using -flat_namespace anywhere (and >> the default is afaik -twolevel_namespace). I Tried linking to V8 >> statically, and with 7.8 non-monolith static libs it worked, but I tried >> again with 7.2 monolithic and it calls into libNode.dylib and crashes. I'll >> try 7.2 with non-monolithic build but even if it works it seems very >> unstable. >> >> Is electron built perhaps with flat_namespace? I'm using an old version >> (1.8, its 2.5 years old). >> >> I'm running out of ideas on how to work around this... >> >> 2019. november 22., péntek 3:18:13 UTC+1 időpontban Ben Noordhuis a >> következőt írta: >>> >>> On Thu, Nov 21, 2019 at 6:10 PM Zoltan B <zben...@gmail.com> wrote: >>> > >>> > Hi! >>> > >>> > I'm running an electron app, that loads native application (using ffi) >>> that renders content into a canvas in electron. This native C++ code has an >>> embedded V8 inside it. >>> > I'm compiling V8 into dynamic libraries (.dylib files) >>> (use_component_build is set to true). >>> > >>> > My issue is that the V8 inside Electron seems to clash with my V8 >>> instance (they are not the same version), but only on macOS. >>> > If you look at the call-stack below of the segmentation fault, you can >>> see that it begins in libv8.dylib, but ends up somehow in libnode.dylib >>> which I can't really explain. >>> > >>> > Thread 16 Crashed: >>> > 0 libnode.dylib 0x0000000108306911 0x107c70000 + 6908177 >>> > 1 libnode.dylib 0x000000010830609c void >>> v8::internal::LookupIterator::Start<false>() + 60 >>> > 2 libv8.dylib 0x0000000118bbc354 >>> v8::internal::JSObject::SetOwnPropertyIgnoreAttributes(v8::internal::Handle<v8::internal::JSObject>, >>> >>> v8::internal::Handle<v8::internal::Name>, >>> v8::internal::Handle<v8::internal::Object>, >>> v8::internal::PropertyAttributes) + 164 (js-objects.cc:3148) >>> > 3 libv8.dylib 0x0000000118a9bc06 >>> v8::internal::Genesis::GetThrowTypeErrorIntrinsic() + 118 (handles.h:144) >>> > 4 libv8.dylib 0x0000000118a9c13d >>> v8::internal::Genesis::AddRestrictedFunctionProperties(v8::internal::Handle<v8::internal::JSFunction>) >>> >>> + 29 (bootstrapper.cc:1109) >>> > 5 libv8.dylib 0x0000000118ab1de5 >>> v8::internal::Genesis::Genesis(v8::internal::Isolate*, >>> v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, >>> v8::Local<v8::ObjectTemplate>, unsigned long, >>> v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 1269 >>> (bootstrapper.cc:5446) >>> > 6 libv8.dylib 0x0000000118a9b209 >>> v8::internal::Bootstrapper::CreateEnvironment(v8::internal::MaybeHandle<v8::internal::JSGlobalProxy>, >>> >>> v8::Local<v8::ObjectTemplate>, v8::ExtensionConfiguration*, unsigned long, >>> v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 89 >>> (bootstrapper.cc:5374) >>> > 7 libv8.dylib 0x00000001188862aa v8::NewContext(v8::Isolate*, >>> v8::ExtensionConfiguration*, v8::MaybeLocal<v8::ObjectTemplate>, >>> v8::MaybeLocal<v8::Value>, unsigned long, >>> v8::DeserializeInternalFieldsCallback, v8::MicrotaskQueue*) + 1722 >>> (api.cc:5697) >>> > 8 libv8.dylib 0x00000001188866fa v8::Context::New(v8::Isolate*, >>> v8::ExtensionConfiguration*, v8::MaybeLocal<v8::ObjectTemplate>, >>> v8::MaybeLocal<v8::Value>, v8::DeserializeInternalFieldsCallback, >>> v8::MicrotaskQueue*) + 42 (api.cc:5856) >>> > >>> > >>> > >>> > Is it possible that when libv8.dylib loads the subsequent .dylib files >>> with dlopen() (such as libv8_platform.dylib etc.) that dlopen somehow >>> fetches the V8 symbols inside the libnode.dylib? >>> > >>> > Electron version I'm using: 1.8.8 >>> > V8 versions I'm using in my app: 7.2 (I tried it with 7.8 too but with >>> the same results) >>> > >>> > Could anyone help me out how to avoid this? >>> >>> Since you're only seeing this on macOS: is anything linked with >>> -flat_namespace? >>> >> -- -- v8-users mailing list v8-users@googlegroups.com http://groups.google.com/group/v8-users --- You received this message because you are subscribed to the Google Groups "v8-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to v8-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/v8-users/b2cf8833-bdd2-4ffb-8229-1fad2c68087d%40googlegroups.com.
