v8_snapshots for arm(32bit) using debian_sid_i386-sysroot

[Jean-François Dagenais]

Hi all!

Just so you can adapt your responses (:-) I am a total newb with chromium and v8. Over the years I have become more of a systems enginee and have never been a web developer.

I have spent the last few days getting a build of libcef/chromium working on buildroot for an arm target (32 bits). FYI, I am not using depot_tools but a tar.gz and implementing the gclient hooks manually, well in my libcef.mk recipe file.

I am instructing chromium's build to use linux:unbundle with buildroot's target sysroot for the target binaries. But in the spirit of reducing dependencies towards the build host as well as buildroot, I have opted to let chromium's build system use the the install-sysroot.py generated sysroots for arm64 (build host) and i386 (v8 snapshots). This was just somewhat blindly following the advice of the error message to invoke install-sysroot --arch=arm64 and i386.

After having to tweak build/config/linux/pkg_config.gni to provide the sysroot argument (-s) to pkg-config.py (?? I don't know how this can work for anyone and why I had to do this.) After a long while, I finally got binaries.

However, the v8_context_snapshot_generator I have, which should be able to run on the build host, doesn't have rpaths to chromium/build/linux/debian_sid_i386-sysroot/... so the action("generate_v8_context_snapshot") from tools/v8_context_snapshot/BUILD.gn fails because it's not finding libraries. ldd shows it's looking at the host rootfs (/). I can hack things with LD_LIBRARY_PATH, but again, I'm thinking: How does this even work for anyone!?

Thanks for helping me understand what's wrong with my setup.

[Jakob Gruber]

You're on the wrong list, the v8_context_snapshot is part of chromium, not v8. In any case, I'm not sure anyone here will be able to help; we usually use the standard build tools and thus don't run into these kinds of issues. Fwiw, +Hitoshi Yoshida who implemented v8_context_snapshots.

 

Thanks for helping me understand what's wrong with my setup.

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/0d39beec-b386-46e0-ae38-134a67b3a0e6n%40googlegroups.com.

[Hitoshi Yoshida]

cc->bcc: v8-dev@

Hi, Jeff,

I'm sorry, I'm not familiar with the non-standard infrastructures ,either.

(To be honest, it is quite difficult to set up the build configuration for v8_context_snapshot_generator in a cross-build environment.)

If it works for you, I recommend to avoid using v8_context_snapshot, with setting "use_v8_context_snapshot=false" in your gn.args.

Then the action is not invoked, and Chromium should run correctly.  Now on ChromeOS and Android, Chrome is built in this setting.

2021年2月24日(水) 15:09 Jakob Gruber <jgr...@chromium.org>:

--

Hitoshi Yoshida (Peria)

email: pe...@chromium.org

[Jean-François Dagenais]

Thanks for your answers guys! So isn't there "major" performance drawbacks of not using pre-made snapshots ? Especially for an older arm cpu system?

[Jakob Gruber]

Depends on how large your initial heap state is / how expensive it is to set up. +Yang Guo may have more details, and I guess you've seen https://v8.dev/blog/custom-startup-snapshots. In any case, your build issues sound solvable (it works with ninja after all), but with a custom environment it may be difficult to get help. 

To view this discussion on the web visit https://groups.google.com/d/msgid/v8-dev/cb7965ed-3872-49b0-b6bc-3270db290406n%40googlegroups.com.

[Jean-François Dagenais]

Thanks for this info! I had not checked this blog post but it sure will give me a lot of useful context to make a more educated decision.

Going over my intuition that I was doing something incorrectly, I tried fooling with LD_LIBRARY_PATH when manually launching v8_context_snapshot_generator exe so the dyn linker would pick-up the libs in debian_sid_i386-sysroot. But even within that sysroot itself, some of the .so's in there depend on a version of libdbus-1 which is not even in the sysroot!

I will post on the main chromium-dev group about this I think... unless you guys believe this discussion belongs here?

[zhaojia...@loongson.cn]

Is it like: "warning: libdbus-1.so.0, needed by ../../build/linux/xxxx/libatk-bridge-2.0.so, not found (try using -rpath or -rpath-link)" and there is a libdbus-1.so.3 in sysroot? I have seen that error message when I cross compile for arm64 target and set use_lld to false, I think it may be related with https://chromium-review.googlesource.com/c/chromium/src/+/2220362.  The error is gone when I use lld linker, so . Hope it helps!

Besides, are you cross compiling for arm(32 bit) on x86 machine? Why the sysroot is arm64 instead of arm?

[Jean-François Dagenais]

Hi Z,

Thanks for your answer, see inline...

> On Feb 25, 2021, at 21:24, zhaojia...@loongson.cn <zhaojia...@loongson.cn> wrote:
>
> Is it like: "warning: libdbus-1.so.0, needed by ../../build/linux/xxxx/libatk-bridge-2.0.so, not found (try using -rpath or -rpath-link)" and there is a libdbus-1.so.3 in sysroot?

Yes, exactly. except these files are all within debian_sid_i386-sysroot, fetched and deflated by install-sysroot.py. So it's weird that the debian sid libraries don't even agree with each other.

> I have seen that error message when I cross compile for arm64 target and set use_lld to false, I think it may be related with https://chromium-review.googlesource.com/c/chromium/src/+/2220362. The error is gone when I use lld linker, so . Hope it helps!

I will look into this, but from what I can tell, these are binary artifact made by debian and archived by chromium a while ago, I did not produce these files...

```
.../build/linux/debian_sid_i386-sysroot$ ~/find_libdbus_dependants.sh
./usr/lib/i386-linux-gnu/libavahi-client.so.3 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libpulse.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/pulseaudio/libpulsecommon-13.0.so depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libdbus-glib-1.so.2.3.4 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libgnome-keyring.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libpulse.so.0.21.1 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libgnome-keyring.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libavahi-client.so.3.2.9 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libpulse.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so.0.0.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatspi.so depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatk-bridge-2.0.so.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libgnome-keyring.so.0.2.0 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libatspi.so.0.0.1 depends on libdbus-1.so.0
./usr/lib/i386-linux-gnu/libdbus-glib-1.so.2 depends on libdbus-1.so.3
./usr/lib/i386-linux-gnu/libatspi.so.0 depends on libdbus-1.so.0

.../build/linux/debian_sid_i386-sysroot$ find -name "libdbus-1.so.*"
./lib/i386-linux-gnu/libdbus-1.so.3.19.11
./lib/i386-linux-gnu/libdbus-1.so.3
```

> Besides, are you cross compiling for arm(32 bit) on x86 machine? Why the sysroot is arm64 instead of arm?

It's not arm64... why do you say that?

Cheers and thanks again for the help!!

[zhaojia...@loongson.cn]

I don't think it's because debian's libraries don't even agree with each other, from the link I posted before, It seems chromium's script specifically replaces some .so's dependency from libdbus-1.so.3 to libdbus-1.so.0 to workaround a lld's bug.Maybe chromium always use lld as linker, and did't test the ld linker? I'm not sure. Are you using clang as compiler and ld as linker? And which version chromium are you compiling?

> It's not arm64... why do you say that?

It's because your first post said so:

> I am instructing chromium's build to use linux:unbundle with buildroot's target sysroot for the target binaries. But in the spirit of reducing dependencies towards the build host as well as buildroot, I have opted to let chromium's build system use the > > the install-sysroot.py generated sysroots for arm64 (build host) and i386 (v8 snapshots). This was just somewhat blindly following the advice of the error message to invoke install-sysroot --arch=arm64 and i386.

[Jean-François Dagenais]

> On Feb 25, 2021, at 23:16, zhaojia...@loongson.cn <zhaojia...@loongson.cn> wrote:
>
> I don't think it's because debian's libraries don't even agree with each other, from the link I posted before, It seems chromium's script specifically replaces some .so's dependency from libdbus-1.so.3 to libdbus-1.so.0 to workaround a lld's bug.Maybe chromium always use lld as linker, and did't test the ld linker? I'm not sure. Are you using clang as compiler and ld as linker? And which version chromium are you compiling?

Yeah, I haven't had time yet to go into the issue you pointed out in detail... I will. I just wanted to get this reply out quick.

I'm using a buildroot built llvm 11.0.1 ld.lld for the linker (well, and compiler) and chromium version 87.0.4280.88

>
> > It's not arm64... why do you say that?
> It's because your first post said so:
> > I am instructing chromium's build to use linux:unbundle with buildroot's target sysroot for the target binaries. But in the spirit of reducing dependencies towards the build host as well as buildroot, I have opted to let chromium's build system use the > > the install-sysroot.py generated sysroots for arm64 (build host) and i386 (v8 snapshots). This was just somewhat blindly following the advice of the error message to invoke install-sysroot --arch=arm64 and i386.

Oh wow, what a nice brain fart! I meant to write --arch=amd64!! The build host is just a regular x86_64 machine. Duh! Sorry!!