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

[Alyssa Ross]

Gurchetan Singh <gurchetansingh@chromium.org> writes:

> On Fri, Jan 19, 2024 at 1:13 PM Alyssa Ross <hi@alyssa.is> wrote:
>>
>> Hi Gurchetan,
>>
>> > Thanks for the reminder.  I did make a request to create the release
>> > tags, but changes were requested by Fedora packaging effort:
>> >
>> > https://bugzilla.redhat.com/show_bug.cgi?id=2242058
>> > https://bugzilla.redhat.com/show_bug.cgi?id=2241701
>> >
>> > So the request was canceled, but never re-requested.  I'll fire off
>> > another request, with:
>> >
>> > gfxstream: 23d05703b94035ac045df60823fb1fc4be0fdf1c ("gfxstream:
>> > manually add debug logic")
>> > AEMU: dd8b929c247ce9872c775e0e5ddc4300011d0e82 ("aemu: improve licensing")
>> >
>> > as the commits.  These match the Fedora requests, and the AEMU one has
>> > been merged into Fedora already it seems.
>>
>> These revisions have the problem I mentioned in my previous message:
>>
>> >> The gfxstream ref mentioned here isn't compatible with
>> >> v0.1.2-rutabaga-release, because it no longer provides logging_base.pc,
>>
>> rutabaga was not fixed to use the new AEMU package names until after the
>> v0.1.2-rutabaga-release tag, in commit 5dfd74a06.  So will there be a
>> new Rutabaga release that's compatible with these release versions of
>> gfxstream and AEMU?
>
> Good catch.
>
> One possible workaround is to build gfxstream as a shared library.  I
> think that would avoid rutabaga looking for AEMU package config files.
>
> But if another rutabaga release is desired with support for a static
> library, then we can make that happen too.

We're exclusively building gfxstream as a shared library.

Looking at rutabaga's build.rs, it appears to me like pkg-config is
always used for gfxstream unless overridden by GFXSTREAM_PATH.

signature.asc
Description: PGP signature