Gdal-bin "Cannot open shared object file"

I’m trying to create a snap package that uses a package called gdal-bin but I’m getting the following runtime error when I try to use one of the commands:

$ gdal-bin.ogr2ogr --help
ogr2ogr: error while loading shared libraries: libblas.so.3: cannot open shared object file: No such file or directory

Here is a snapcraft yaml that isn’t from my actual project but it isolates and reproduces my problem:

name: gdal-bin
base: core18 # the base snap is the execution environment for this snap
version: '0.1' # just for humans, typically '1.2+git' or '1.3.2'
summary: gdal-bin snap package
description: |
  gdal-bin snap package

grade: devel # must be 'stable' to release into candidate/stable channels
confinement: devmode # use 'strict' once you have the right plugs and slots

parts:
  gdal-bin:
    plugin: nil
    stage-packages:
    - gdal-bin

apps:
  ogr2ogr:
    command: ogr2ogr

The program is trying to load the dependency from the following:

$ ldd /snap/geojobs/current/usr/bin/ogr2ogr
..
        libblas.so.3 => /usr/lib/x86_64-linux-gnu/libblas.so.3 (0x00007f2067417000)
..

But it doesn’t exist there:

$ cd /snap/gdal-bin/current
$ sudo find . -name "*blas*"
./usr/lib/x86_64-linux-gnu/blas
./usr/lib/x86_64-linux-gnu/blas/libblas.so.3
./usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
./usr/share/doc/libblas3

The issue it seems is that the install seems to not have created a link to the library.

As a work around, I tried running ldconfig in an install hook script but that didn’t fix my issue. Changing my snapcraft yaml apps section to the following did fix my issue (NOTE: I also had the same problem with lapack):

...
apps:
  ogr2ogr:
    command: ogr2ogr
    environment:
      LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/x86_64-linux-gnu/blas:$SNAP/usr/lib/x86_64-linux-gnu/lapack

Why is the gdal-bin install faulty? Is there an issue on my side? Or is there a bug with snapcraft? Is there a more elegant way to work around this? Help please. Thank you!

1 Like

Using LD_LIBRARY_PATH is the correct way to do this AFAIK since usr/lib/x86_64-linux-gnu/blas is not a normal path on the library search path (unlike for example the parent directory usr/lib/x86_64-linux-gnu).