Christopher James Halse Rogers <chris@cooperteam.net> writes:
> For apitrace we ended up using the $LIB dynamic expansion to let the
> dynamic loader handle this itself
> (https://github.com/apitrace/apitrace/pull/177).
>
> That's presumably applicable to fips and vogl also.
Yes, that $LIB thing is really convenient for this.. The last time I
looked, it wasn't available within LD_PRELOAD like it is for
LD_LIBRARY_PATH.
But yes, we already are using this in vogl and fips where possible.
> On the packaging side you just split the wrapper objects into their own
> packages, (cf: [1]).
Thanks for the pointer to the apitrace packaging. That will be helpful.
I think the only piece I'm missing is that for waffle we really do want
to have multiple architecture-specific utility binaries available on
PATH. Unlike apitrace, vogl, and fips where the wrapper can investigate
the target and decide which library to load, with the waffle utility
it's the user's choice which binary he wants to run.
So I'm wondering if there's a precedent for packaging and naming in a
case like that.
> This doesn't help with package dependencies, though. Ideally installing
> apitrace-gl-frontend:amd64 would also install
> apitrace-gl-tracers:{all-the-enabled-foreign-archs}. I don't think
> there's any
> way of specifying that relationship at the moment, though.
Right. That would be nice. But at the very least we can put in place a
kind message that provides some guidance as soon as the user tries to
use the wrapper on a binary for which the necessary dependent package is
missing.
Thanks for the help, everyone.
-Carl
--
carl.d.worth@intel.com
Attachment:
pgpTTocsChI44.pgp
Description: PGP signature