Ubuntu Snap Custom Library Locations

[metaldave]

Hi, friends.

I believe we're encouraged to use the Snap application manager method of installing the latest VLC with Ubuntu 20.04. Unfortunately, there's not a great amount of documentation as to how the read-only (RO) Snap mount location works versus the local customization within the user directories.

I'm new to Ubuntu but fairly savvy with Linux, so I've figured it out to a point. For example, I can now make a direct correlation between themes, extensions, and plug-ins to find equivalencies between the user directories and the RO filesystem. For example:

Code: Select all

~/snap/vlc/current/.local/share/vlc/lua/ == /snap/vlc/current/usr/lib/vlc/lua ## Extensions, Interfaces, Playlists, etc.

The above would seem to provide the equivalent path to customizing extensions, etc. I am hoping there is a similar mechanism in place regarding custom libraries.

The read-only (ro) filesystem containing libraries relevant to VLC appears to be in the following locations:

Code: Select all

/snap/vlc/current/usr/lib/ ## Some Libraries (ro) /snap/vlc/current/usr/lib/vlc/ ## Some Libraries (ro) /snap/vlc/current/usr/lib/x86_64-linux-gnu/ ## Main Libraries (ro)

Are there equivalent locations in the ~/snap/vlc/current/.local/share/vlc/ directory where one could place an additional or alternate library to supplement the functionality of the application?

To provide a use-case example: I am focusing on Blu-ray disc playback as part of my workflow. As a library critical to Blu-ray playback, a copy of libaacs.so.0.6.0 (with a corresponding symlink of libaacs.so.0 pointing to it) is found in the /snap/vlc/current/usr/lib/x86_64-linux-gnu/ directory. If I want to put a different version of libaacs into service (whether newer, older, or alternate), can I do so and where would I put it?

Again, I imagine that I'd want to put it somewhere within the ~/snap/vlc/current/.local/ directory. Obviously, this user library location would need to have higher priority (i.e. scan first) over the libraries stored in the read-only file system. Assuming I have a valid custom library and it loaded, I would hope it would prevent the copy in the RO filesystem from loading. Again, this is just my speculation on how something like this would work.

Any feedback or direction would be appreciated. Thank you!

- Dave

[Rémi Denis-Courmont]

How libraries are loaded is up to the run-time, not VLC. There are no special provisions normally, nor in the Snap version of VLC.

[metaldave]

How libraries are loaded is up to the run-time, not VLC. There are no special provisions normally, nor in the Snap version of VLC.

Rémi,

I appreciate the feedback. I'll look into this a little further to see if I can leverage appropriately.

For clarification, you're indicating the snapd run-time, correct? In other words, libraries available for snap version of VLC would have to be loaded within the Snap environment (not at the OS level). If that's the case, there is a follow-up inquiry to be made with the folks at Canonical/Ubuntu.

On that note, can/does VLC reference a library outside of its package? Based on the Snap documentation, I get the impression that any libraries an application needs are supposed to be bundled and referenced within the application's snap package.

Thanks again,

- Dave

[Rémi Denis-Courmont]

No. I mean the C run-time. There is no snapd in normal use.

[metaldave]

Thank you for the help. I have been thinking on this configuration for a while, and I'm still not coming up with a method to use external shared object libraries with the snap implementation of VLC.

Maybe I should approach this a different way. It seems the snap filesystem creates a virtual translation between it and the host filesystem. For example, ~/snap/vlc/current/.local/share/ on the host filesystem is the equivalent to /home/<username>/snap/vlc/current/.local/share/ within the VLC snap filesystem. Is there already a directory on the host filesystem the VLC app will automatically scan and use available shared object libraries?

If an automatic scan and use is not possible, then can we configure something via the ~/snap/vlc/common/vlcrc file in the local host filesystem to set a path for a particular locally stored library?

I was also hoping for using a shared library would be a method similar to installing local plugins or extensions. Examples of shared object libraries I'm hoping to maintain outside of the VLC snap image are libaacs.so.0 and libbdplus.so.0. How can I get the VLC image to look outside of its image to find and use these libraries?

I also entertain the idea this functionality may not be possible with the snap version of VLC, and I might need to go with compiling my own. Ideally, we should be able to function within the snap ecosystem, but this might be a natural fork in the road.

Thanks again for your help and feedback!

[Rémi Denis-Courmont]

What part of "libraries are loaded by the run-time" do you still not understand?

[metaldave]

What part of "libraries are loaded by the run-time" do you still not understand?

The short answer: it's the part that goes, "libraries are loaded by the run-time."

My apologies for any confusion. I believe we're speaking of two different things, so please allow me to establish a nomenclature and get us on the same page.

In actuality, I believe we're speaking of Static versus Dynamic libraries (great article here). For further reference, here's a great thread with various interpretations on the difference between the C/C++ Standard and C/C++ Runtime libraries.

Using those articles as a basis for the conversation, I would submit to you that Standard and Runtime libraries are, most certainly, considered "static" libraries as they're "baked-in" to the application upon compile. By contrast, "dynamic" libraries are pre-compiled for use by any number of applications. The terminology "shared object" is synonymous with "dynamic" as pertaining to compiled binary libraries.

I've been referencing shared object libraries (like libbdplus.so.0 and libaacs.so.0), and I believe you're considering these to be runtime libraries. I believe this is the source of the mis-understanding. VideoLAN does distrubte the source for libbdplus and libaacs). While aacs.h is included with the source code and may be used as a runtime library in the application code, libaacs may also be compiled into a dynamic library.

The whole point of using these dynamic libraries is to have the ability to update their functionality in a modular fashion. As the snap packages include an independent, mini filesystem, they include a number of shared object (dynamic) libraries for basic functionality (like libbsd.so.0, for example). As a more pertinent example, the VLC snap distribution actually includes a copy of the libaacs v0.6.0 dynamic library:

Code: Select all

/$ ll /snap/vlc/current/usr/lib/x86_64-linux-gnu/libaacs* lrwxrwxrwx 1 root root 16 Jun 30 2017 /snap/vlc/current/usr/lib/x86_64-linux-gnu/libaacs.so.0 -> libaacs.so.0.6.0 -rw-r--r-- 1 root root 113360 Jun 30 2017 /snap/vlc/current/usr/lib/x86_64-linux-gnu/libaacs.so.0.6.0

Notably, VideoLAN is distributing libaacs v0.11.0 source as the latest release. If this were a non-snap distribtuion, I would compile a new shared object (dynamic) library from the source code and update the symlink for libaacs.so.0 to point to that new shared object library. Unfortunately, the snap offers read-only filesystem and does not allow for one to re-write or replace a symlink within.

I hope this more adequately explains my connundrum.

[metaldave]

As I was unable to resolve the use of dynamic shared libraries with the Snap installation, I removed that application. As a next step, I installed the version from the focal repository. I used the apt package manager, but you can use the Ubuntu Software app manager to get this version via the GUI as well.

Using this method, the binary and the various packages dependencies directly into the filesystem (as you would expect). Additionally, various dynamic libraries are installed in /usr/lib/x86_64-linux-gnu/. Installing and using additional libraries (or symlinks) in this location are easy enough and work without further intervention.

The only drawback is the version via the focal distribution is a revision or two behind the version distributed via snap (v3.0.9.2-1 versus v3.0.11). Now that I have confirmed the location of the dynamic libraries with a "normal" install of VLC, I may remove and try again with the Snap. If the /usr/lib/x86_64-linux-gnu/ is accessible to the snap RO filesystem via some type of aliasing, I may be able to manipulate the dynamic libraries again. I'll post my findings for future reference.