@kyrofa I finally fixed all the new snapcraft changes to get slam toolbox released before ROSCon.
It turns out because of pluginlib, I need to release in classic confinement for technical reason I don’t understand behind the scenes of snapcraft. I have users that are trying to use this right now and this is a blocker to their deployment of robot assets. I’m not able to get access to the libraries I need in strict confinement on run-time though it builds fine.
What happens is the usual pluginlib “do you have any plugins?” errors. To make pluginlib work inside the snap I needed to manually set the library paths for blas and lapack, so my guess is whatever the issue with strict that classic doesn’t have is related to accessing those libraries.
Failed to create solver_plugins::CeresSolver, is it registered and built?
Exception: Failed to load library /snap/slam-toolbox-melodic/x1/opt/ros/melodic/lib/libceres_solver_plugin.so.
Make sure that you are calling the PLUGINLIB_EXPORT_CLASS macro in the library code, and that names are consistent between this macro and your XML.
Error string: Could not load library (Poco exception = liblapack.so.3: cannot open shared object file: No such file or directory).
I don’t see this when compiled in classic or devmode. No errors on compile time.
@stevemacenski Can you please outline the specific reasons why classic is required - to me, the argument of “it just works when classic but doesn’t when strict” is not detailed enough - are there specific denials listed in dmesg etc which you could provide to justify this request? Is the smap trying to access libraries from the host system? This is usually discouraged since you can’t be certain what libraries will be available etc.
@alexmurray I am by no means a snapcraft expert so I can try as much as possible. The issue lies in ROS’s pluginlib which dynamically locates and loads plugins for use.
Typical ROS applications I haven’t had problems with strict confinement, but since pluginlib needs to find libraries in the snap and load them, there’s been a few compromises needing to be made, including manually pointing the library path to blas and lapack, as well as apparently whatever changes behind the scenes in snapcraft when building in confinement.
Not being sure what’s installed is kind of the point of dynamically loading plugins. Nothing is trying to access the host system.
@kyrofa is very knowledgable about both ROS and snapcraft, he may be able to shed some light.
The source code is available and the only issue is in pluginlib which doesn’t break containment as far as I know, it’s just looking for the so file of the plugin to load, which cant be found for some reason in strict confinement only.
Thanks for the second ping, @stevemacenski. Not sure how I missed the first one, sorry about that! Let me dig into this a bit tomorrow and see if we can’t figure out what’s happening here.
For more reference, separate of this snap, I’ve tried to snap rviz plugins with the hope of trying to be able to load them from the host system (which as may not shock you, wasn’t possible). But in that testing I installed rviz inside the snap and tried to get them to talk in that way before trying to get out of the snap. In this case I also failed.
This doesn’t seem to be to be a problem with any particular type or use of plugin, but pluginlib + strict snaps themselves.
I tried to come up with a simple reproducer. I present you with: a snap of the simplest pluginlib usage imaginable. If there was an inherent issue with pluginlib and strict confinement, this shouldn’t work, but it does.
@stevemacenski you’re obviously doing significantly more than this, but do you agree that, if that example works, there’s no inherent issue with pluginlib and strict confinement? Any chance you can come up with a minimum reproducer for this issue? I won’t pretend to be an expert in ceres or the slam toolbox .
You’re referring to this, I assume? The only reason those should be required is because you’re using classic: classic snaps don’t get the same environment generated for them as devmode or strict.
I could definitely believe it may relate to Ceres, I know Ceres also tries to dynamically locate libraries to use different solvers, but I don’t think its related to that. The error I’m getting is pluginlib telling me it can’t locate/read the library, not that it failed to load / ceres seg faulting / etc. It is interesting though that it finds the library, but fails to load it, if you look at the error in my original message.
Its strange to me that this works fine in other forms of confinement but not strict.
The only reason those should be required is because you’re using classic
That is inconsistent with my experiences. Those were originally added when I only worked in devmode because it wasn’t worth it to me for internal tools to use classic/strict and that was the only way I could get the plugins to load. Your examples working clearly is consistent with your view. Did something change from snapcraft in 16.04 that makes this a different behavior?
An aside:
From the documentation on strict
It won’t be able to access the network
By definition that can’t happen in ROS, since we need network access to talk to the ROS master / pubsub. Is that not justification enough, regardless of my plugin woes to get slam-toolbox approved for classic confinement?
Yeah it’s hard to know what’s happening without a minimal reproducer, I’m afraid.
That’s interesting. Those paths should have already been on the LD_LIBRARY_PATH in non-classic confinements, and it should be that way both with and without bases. There’s no harm having those lines, but I’ll admit I’m confused as to why they are necessary.
From the documentation on strict
It won’t be able to access the network
By definition that can’t happen in ROS, since we need network access to talk to the ROS master / pubsub
Indeed, strict confinement means the snap by default can’t really do much. However, that’s what interfaces are for-- opening up the confinement bit by bit in a way that the user can selectively deny if they so choose (think installing an app from the Google Play store). You probably need at least the network plug, maybe network-bind as well.
I have both plugs, but how the documentation reads is that I can’t publish a strict confined snap to the snap store with any network plugs. Is that incorrect?
That is indeed incorrect-- you can definitely publish a strict snap with a set of interfaces declared! There are some restricted ones, like ones that give the snap the ability to own the system in various ways, but for the most part, you should be good to go. Can you point me to where the docs imply this? I’d love to fix it, but these are the only docs of which I’m aware.
I foraged wide and far to find reference to the doc I found that implied that, but alas I cannot find it. If I were to guess I skimmed something or had an old page cached.
I’ll have to take a deeper look at this at some point. Unfortunately I’m a bit pressed for time so I’m going to temporarily host the snap on a public facing server to get folks moving that need it & I’ll swing back on this after conference season. If your demo worked, there’s something else wacky here.
.