ROOT 6, Ubuntu Snap installation, Access to system include directories

Hi all,

I don’t seem to have proper access to system include directories from a Ubuntu snap installed ROOT instance:

$ file /usr/include/ceres/ceres.h
/usr/include/ceres/ceres.h: C source, ASCII text

but

root [10] .!ls /usr/include/ceres
ls: cannot access ‘/usr/include/ceres’: No such file or directory
root [11] #include <ceres/ceres.h>
ROOT_prompt_12:1:10: fatal error: ‘ceres/ceres.h’ file not found
#include <ceres/ceres.h>
^~~~~~~~~~~~~~~

Is this a consequence of the snap package isolation ?

ROOT Version: 6.30/02
Platform: Ubuntu 20.04.06 LTS
Compiler: Ubuntu 11.4.0-1ubuntu1~22.04


What does:

ls -l /usr/include/ceres
ls -l /usr/include/ceres/ceres.h

show?

$ ls -l /usr/include/ceres
insgesamt 464
-rw-r–r-- 1 root root 10902 Mär 22 2018 autodiff_cost_function.h
-rw-r–r-- 1 root root 6397 Mär 22 2018 autodiff_local_parameterization.h
-rw-r–r-- 1 root root 5938 Mär 22 2018 c_api.h
-rw-r–r-- 1 root root 2689 Mär 22 2018 ceres.h
-rw-r–r-- 1 root root 4221 Mär 22 2018 conditioned_cost_function.h
-rw-r–r-- 1 root root 2492 Mär 22 2018 context.h
-rw-r–r-- 1 root root 6361 Mär 22 2018 cost_function.h
-rw-r–r-- 1 root root 21622 Mär 22 2018 cost_function_to_functor.h
-rw-r–r-- 1 root root 18974 Mär 22 2018 covariance.h
-rw-r–r-- 1 root root 3125 Mär 22 2018 crs_matrix.h
-rw-r–r-- 1 root root 15962 Mär 22 2018 cubic_interpolation.h
-rw-r–r-- 1 root root 10608 Mär 22 2018 dynamic_autodiff_cost_function.h
-rw-r–r-- 1 root root 2405 Mär 22 2018 dynamic_cost_function.h
-rw-r–r-- 1 root root 7728 Mär 22 2018 dynamic_cost_function_to_functor.h
-rw-r–r-- 1 root root 7530 Mär 22 2018 dynamic_numeric_diff_cost_function.h
-rw-r–r-- 1 root root 3983 Mär 22 2018 evaluation_callback.h
-rw-r–r-- 1 root root 2870 Mär 22 2018 fpclassify.h
-rw-r–r-- 1 root root 6473 Mär 22 2018 gradient_checker.h
-rw-r–r-- 1 root root 5001 Mär 22 2018 gradient_problem.h
-rw-r–r-- 1 root root 15613 Mär 22 2018 gradient_problem_solver.h
drwxr-xr-x 2 root root 4096 Jan 23 2023 internal
-rw-r–r-- 1 root root 8607 Mär 22 2018 iteration_callback.h
-rw-r–r-- 1 root root 34723 Mär 22 2018 jet.h
-rw-r–r-- 1 root root 13183 Mär 22 2018 local_parameterization.h
-rw-r–r-- 1 root root 14516 Mär 22 2018 loss_function.h
-rw-r–r-- 1 root root 3161 Mär 22 2018 normal_prior.h
-rw-r–r-- 1 root root 14939 Mär 22 2018 numeric_diff_cost_function.h
-rw-r–r-- 1 root root 3537 Mär 22 2018 numeric_diff_options.h
-rw-r–r-- 1 root root 6793 Mär 22 2018 ordered_groups.h
-rw-r–r-- 1 root root 22708 Mär 22 2018 problem.h
-rw-r–r-- 1 root root 22317 Mär 22 2018 rotation.h
-rw-r–r-- 1 root root 4813 Mär 22 2018 sized_cost_function.h
-rw-r–r-- 1 root root 48120 Mär 22 2018 solver.h
-rw-r–r-- 1 root root 5581 Mär 22 2018 tiny_solver_autodiff_function.h
-rw-r–r-- 1 root root 5379 Mär 22 2018 tiny_solver_cost_function_adapter.h
-rw-r–r-- 1 root root 13496 Mär 22 2018 tiny_solver.h
-rw-r–r-- 1 root root 19549 Mär 22 2018 types.h
-rw-r–r-- 1 root root 2378 Mär 22 2018 version.h

$ ls -l /usr/include/ceres/ceres.h
-rw-r–r-- 1 root root 2689 Mär 22 2018 /usr/include/ceres/ceres.h

now

root.exe -b
root [] .! ls -l /usr/include/ceres

i.e. .! call a subshell and there is no reason that it gives a different result than when running directly on the shell.

That is the problem. See my initial post.
I do it again:

root [0] .! ls -l /usr/include/ceres
ls: cannot access ‘/usr/include/ceres’: No such file or directory

My suspicion is, this behaviour has something to do with the isolation mechanics of these ubuntu snaps.

@James-Carroll might be able to help you. See also A Snap package for ROOT on Linux - ROOT

Thanks for the hint. I will install the binary tomorrow and see if the problem still persists. If not I will contact James Carroll. Will report any progress in this thread.

Here we go. Excerpt from James’ blog entry:

Sandboxing

Most snap packages are under a sandboxing model that might subtly interfere with a user’s regular workflow. This means that the ROOT snap cannot just access a user’s camera or microphone for example, since this makes little sense for ROOT. However, one notable feature is that ROOT is limited to accessing files in the users home directory (aside from over the network). Furthermore, the snap will be prevented from accessing hidden files/folders in the top level of the home directory itself, such as $HOME/.ssh.

Case closed then. Will go with the binary. Thanks again for the link.

Hey,

There’s a very hidden copy of CMake and GCC in the snap which means you might be able to compile third party libraries, but I’ve no idea of Ceres in particular as to whether it’s viable. In theory though, you might be able to run root-framework.cmake in Ceres git repository alongside then root-framework.make; and then either root-framework.run executableName or running root with import directories configured if doing it interactively.

I generally don’t recommend people actually use it however. There’s a few very specific situations it comes in handy (E.G I know one user who uses these hidden wrappers to teach ROOT at the undergraduate level by making executables with gcc rather than the interpretter) but for the most part its a bad user experience that probably would cause more confusion than benefit if it was more publically known.

Unfortunately, direct access to the system paths would break the snap in general cases because whilst it would actually be possible to put the system include paths in the sandbox, the result would end up being mismatches between versions and other ABI compatibility concerns. Essentially the snap is designed around a bundling everything and the kitchen sink approach, and struggles when the libraries aren’t actually available.

Ultimately I do think that official binary builds would be more appropriate to your needs (and likely the Conda package too), but it’s actually quite easy to build snaps and you could potentially build your own version of ROOT with Ceres already in it. I’ve an example of using ROOT alongside Geant4, QT, and a few others, to build the Gate snap which actually works just fine for that program!

Building snaps in general on traditional Linux machines is quite easy, instructions for Ubuntu would just be:

sudo snap install snapcraft --classic
sudo snap install lxd
sudo lxd init --auto
git clone https://github.com/MrCarroll/gate-snap
cd gate-snap
snapcraft
sudo snap install my_snap.snap --dangerous

With snapcraft itself handling the setup of the build environment in an LXD container so it doesn’t mess with your main system.

Ultimately I don’t know if that’s viable for ROOT + Ceres, but it could certainly be an option worth exploring.

1 Like

Thanks a lot for all the info. Building a customized ROOT snap will probably come in handy in a different project i am going to work on. At the moment I have a lot of prototyping stuff that requires pulling in all kinds of libraries. The ROOT binary is then obviously the way to go here. Thanks again for the very helpful post. Cheers