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.
For rutabaga, I ended up having to patch a little bit the shared
library, to fix SONAME:
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
