I’m trying to have VLC’s snap build fixed (although the issue is the same on any recent ubuntu, snap or not), and I’ve been advised by @Wimpress to come here for help, so here I am
Basically, our builds are failing because we generate a plugin cache which involves loading and unloading every plugin at build time.
The problem is, some modules depend on
libmirclient, which in turn depends on
libprotobuf-lite. As it turns out, protobuf doesn’t seem to handle multiple shared libraries being loaded/unloaded by the same program quite well.
This issue is demonstrated by this ticket on their bugtracker: https://github.com/google/protobuf/issues/206
On VLC’s side, we are tracking the issue under https://trac.videolan.org/vlc/ticket/18329 (which is probably a bit more detailed than what I wrote here)
We work around the build issue, but things would be worth an unpredictable at runtime. For instance, switching between video output modules would result in a crash, possibly just playing a video file, then an audio file, and a video file again would crash, using the chromecast module would definitely crash after the 2nd media… so I really believe that this is something that needs to be fixed, but I don’t see a way out that doesn’t require a fix in protobuf, and as you can see the issue was closed as
Any help, idea, hints would be highly appreciated! Thanks a lot in advance
Hi @chouquette, thanks for bring this discussion here I’ve asked one of the Mir developers to come and join the discussion.
I work on the Mir team and know a little about this. Protobuf unloading has caused us these exact problems in the past, this is our original bug in Mir:
We found that libprotobuf exported symbols that should only have come from libstdc++, so have added this patch to protobuf upstream to make the linker script more selective about the symbols it exports, which should fix the problem you’re seeing:
Can you check if the version of protobuf you’re using includes that patch?
Thanks a lot for stepping in!
By looking at the package sources, I’m enclined to say “it is not using this patch” (http://archive.ubuntu.com/ubuntu/pool/main/p/protobuf/protobuf_3.0.0.orig.tar.gz doesn’t seem to include the map files, not the editions in autotools related files)
However by looking at the list of exported symbols, it seems only google symbols are exported: https://pastebin.com/byh8kBtP (I assumed that undefined symbols are not the issue here, but I’ll gladly stand corrected if that was wrong)
I think it is the fact those symbols are being declared (even though they’re undefined) that is the problem. https://bugs.launchpad.net/mir/+bug/1391976/comments/6 suggests that.
You’re right that the upstreamed patch is missing in archive, but I see evidence of an older patch to try fix this issue (seems to work too), check out this diff: https://launchpadlibrarian.net/311122635/protobuf_3.0.0-9ubuntu1_3.0.0-9ubuntu1alf1.diff.gz
I’m still quite unclear on the history of this. Will keep digging.
There is a PPA with the upstream patch applied to protobuf:
see “protobuf - 3.0.0-9ubuntu1alf1” - could you test VLC with it and see if it helps?
Sorry about the delay.
I tried both the upstream and the PPA versions, neither seemed to solve our issue. However it seemd the patches included in the PPA are already applied in the upstream package.
In any case, the results are the same
sorry for my delay now. Ok, we’ll have a look to see what’s missing from where.
@greyback @chouquette What is the status of this?
No progress really as I was unable to reproduce the issue locally, and even working with @chouquette I was unable to determine the difference. Then it slipped down my todo list.
Thanks for the ping, I’ll try looking again