On Fri, 8 Dec 2023, Kalev Lember wrote:
On Fri, Dec 8, 2023 at 1:00 PM Martin Storsjö <mar...@martin.st> wrote:
On Fri, 8 Dec 2023, Kalev Lember wrote:
> As for dlopening, I think instead of version checks, it would
make sense to
> try to dlsym() all of the actual required symbols, and error
out in init if
> anything is missing. That should make it all super flexible
and resilient to
> e.g. struct size changes that would normally be an ABI change.
How would that help, if e.g. the SEncParamExt struct in
svc_encode_init
would change layout/size - which part would notice that change?
Ah, hm, I didn't think this through apparently :) This would indeed still be
an issue.
I guess maybe dlopening the soname version that matches the headers (e.g.
libopenh264.so.7) would work then? With the expectation that upstream bumps
soname whenever the struct layout/size changes.
Yeah I guess that would work, it's all up to who has the responsibility
for keeping it in sync. At some point, I envisioned that one could run it
with e.g. -openh264_lib /path/to/my/libopenh264.so, and in such a
scenario, we definitely would need some sort of reassurance that we're
using the right ABI.
But anyway, good that we agree how this works. And this wasn't relevant
for our current way of linking it here anyway, so the patch still is ok
(and can be pushed later if nobody else has further opinions on it).
// Martin
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
