qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream


From: Gurchetan Singh
Subject: Re: [PATCH v13 0/9] rutabaga_gfx + gfxstream
Date: Wed, 13 Sep 2023 21:10:26 -0700



On Wed, Sep 13, 2023 at 6:49 AM Marc-André Lureau <marcandre.lureau@gmail.com> wrote:
Hi

On Wed, Sep 13, 2023 at 5:08 AM Gurchetan Singh
<gurchetansingh@chromium.org> wrote:
> On Tue, Sep 12, 2023 at 6:59 AM Marc-André Lureau <marcandre.lureau@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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]