for shared libs that get dlopened (like the ime thing), I don't think we have a reasonable alternative to building it in a Debian chroot

re #1: Would option 1 (removing --pack-dyn-relocs=relr from termina) be a reasonable alternative?

i don't think that would be sufficient.  the shared libs we produce are going to use other shared libs, and those libs/ABI settings are going to be from our sysroot.  but the shared lib is going to be loaded into the Debian system which has a completely different set of libs/ABI settings.

other people trying to distribute shared libs tend to have an ancient distro chroot laying around and doing all their builds in that so they only rely on really old ABI settings and are portable across all sorts of distros/versions.  but they also try to limit the packages they build against (just glibc and gcc for example).  for the people building against UI libs (e.g. games that use SDL/GTK), you're pretty much guaranteed to be in the equiv of DLL hell.

i don't think we need to worry about any of that, especially for an initial release.  officially we only support Debian, and even then it's Debian Testing.  so lets create a Debian chroot to build these packages and re-evaluate.  i think smbarber@ has this working already for the .deb creation ?

With the virtwl-patched packages, I committed the source debs and then used kokoro to build them with pbuilder against Debian stretch. https://chromium.googlesource.com/chromiumos/containers/cros-container-virtwl/+/master/kokoro/build.sh disclaimer: I never got cross-compilation working with that setup, although it should be supported.

We could also look at using apt pinning and pulling in packages from buster, but those could have the same ABI problems.

What are the packages that we would need to build here? mesa and xwayland?

I'm not sure if we need Debian packaged binaries to use our shared objects.

I've got a franken build of:
- tatl built mesa (w/ mesa gbm)
- tatl built Xwayland
Spawned by sommelier with the existing /opt/google/cros-container method of invocation.  All of the shared libraries come from /opt/google (as verified by /proc/PID/maps) and my shared libraries include .relr.dyn sections (as verified by readelf -S).

With this setup I can run an unmodified GL application (eglgears_x11 or glxgears) which uses the stretch libGL.so and virtio_gpu_dri.so to get virtualized GPU via virgl.

As long as we can limit the usage of shared libraries to our Xwayland instance, and then have all the client apps using the system libraries and then just communicate using existing protocols, shouldn't we be fine?  We might need a newer version of mesa than stretch, but using buster's as smbarber suggest sounds like a better option than providing our entire own set of those libraries.

if the apps all communicate through wayland/X protocols, then there's no need to create custom shared libs.  if you need to produce a (e.g.) libGL.so that apps would use directly, then we must build it using Debian tooling/environment.
i defer to you graphics experts to determine what is necessary in this space.

we also have a project which creates a shared lib for an IME framework which is expected to be dlopened directly into the process's runtime, so we can't use our own sysroot/compiler for that.

The plan of record is to ship debian native packages instead of using the bind mounted ones. Closing issue.