On Wed, Sep 13, 2023 at 6:49 AM Marc-André Lureau < marcandre.lur...@gmail.com> wrote:
> Hi > > On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh > <gurchetansi...@chromium.org> wrote: > > On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau < > marcandre.lur...@gmail.com> wrote: > >> Packaging aemu and gfxstream is a bit problematic. I have some WIP > >> Fedora packages. >> > >> AEMU: > >> - installs files under /usr/include/host-common and > >> /usr/include/snapshot. Can this be moved under /usr/include/aemu > >> instead? > >> - builds only static versions of libaemu-host-common.a and > >> liblogging-base.a (distros don't like static libs much) > >> - could liblogging-base(.a,.so,..) also have "aemu" name in it? > >> - libaemu-base.so is not versioned > >> - I can't find a release tarball, nor the (v0.1.2) release tag > >> - could have a README file > >> > >> I am not very familiar with cmake, so it's not obvious how to make the > >> required changes. Would you like me to open an issue (where?) or try > >> to make some patches? > > > > > > I filed an internal bug with all the issues you listed: Android side > should fix this internally. > > > > I see a few options for packaging: > > > > 1) Punt on gfxstream/AEMU packaging, just do rutabaga > > > > gfxstream is mostly useful for Android guests, and I didn't expect > anyone to actually package it at this point since most here are interested > in Linux guests (where gfxstream VK is headless only right now). Plus > ioctl-fowarding > API forwarding for security and performance, so I'm not > sure if it'll have any sticking power even if everything is supported > (outside of a few niche use cases). > > > > Though, I sense interest in Wayland passthrough for dual Linux use > cases. I put up: > > > > crrev.com/c/4860836 > > > > that'll allow packaging on rutabaga_gfx and even CI testing without > gfxstream, since it is designed to function without it. We could issue > another rutabaga-release tag, or you can simply add a patch (a common > packaging practice) on the Fedora package with the "UPSTEAM label". > > > > 2) Actually package gfxstream only > > > > Probably an intermediate solution that doesn't introduce > versioning/static library issues would be just to have a copy of AEMU in > the gfxstream repo, and link it statically. Will need another release > tag/commit of gfxstream. > > > > 3) Don't package at all > > > > For my particular use case since we have to build QEMU for sources, this > is fine. If upstream breaks virtio-gpu-rutabaga.c, we'll send a patch and > fix it. Being in-tree is most important. > > > > Let me know what you prefer! > > > > I would rather have standard packaging of the various projects, so we > can test and develop easily. > Ack. Here are the requested changes: - https://android-review.googlesource.com/q/topic:%22aemu-package-fix%22 - crrev.com/c/4865171 The main change is: https://android-review.googlesource.com/c/platform/hardware/google/aemu/+/2751066 Once that's okay for packaging, I'll ping harder on v0.1.2 gfxstream/AEMU release tags. Let me know if you want another release tag for rutabaga, or if just patching in upstream changes would be acceptable. For rutabaga, I ended up having to patch a little bit the shared > library, to fix SONAME: > Landed as crrev.com/c/4863380. > > diff --git a/ffi/Makefile b/ffi/Makefile > index d2f0d38..7efc8f3 100644 > --- a/ffi/Makefile > +++ b/ffi/Makefile > @@ -47,13 +47,13 @@ build: > > install: build > ifeq ($(UNAME), Linux) > - install -D -m 755 -t $(DESTDIR)$(libdir) $(OUT)/$(LIB_NAME) > + install -D -m 755 $(OUT)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > endif > ifeq ($(UNAME), Darwin) > - install_name_tool -id $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME) > + install_name_tool -id > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > $(DESTDIR)$(libdir)/$(LIB_NAME) > endif > - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION) > - ln -sf $(DESTDIR)$(libdir)/$(LIB_NAME) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) > + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) > $(DESTDIR)$(libdir)/$(LIB_NAME).$(RUTABAGA_VERSION_MAJOR) > + ln -s $(LIB_NAME).$(RUTABAGA_VERSION) $(DESTDIR)$(libdir)/$(LIB_NAME) > ifeq ($(UNAME), Linux) > install -D -m 0644 $(SRC)/share/rutabaga_gfx_ffi.pc > $(DESTDIR)$(libdir)/pkgconfig/rutabaga_gfx_ffi.pc > install -D -m 0644 $(SRC)/include/rutabaga_gfx_ffi.h > $(DESTDIR)$(includedir)/rutabaga_gfx_ffi.h > diff --git a/ffi/build.rs b/ffi/build.rs > new file mode 100644 > index 0000000..efa18d3 > --- /dev/null > +++ b/ffi/build.rs > @@ -0,0 +1,3 @@ > +fn main() { > + > println!("cargo:rustc-cdylib-link-arg=-Wl,-soname,librutabaga_gfx_ffi.so.0"); > +} > > > The package is a bit unconventional, since it's a rust project > providing a C shared library. I am not sure I did Fedora packaging > right, let see: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=2238751 > > > -- > Marc-André Lureau >
