The correct way to search for external libraries LD_LIBRARY_PATH

Hi all.

If I have 2 programs in the snap package, one uses for example libraries on the path $SNAP/QT/5.5 and the other $SNAP/QT/5.6, then how correctly is it written to this file?

I use the generated desktop-launcher file to start the programs.
In it, I tried to write the path in this form:

#setting for app
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP/QT

but the programs continue to look for libraries elsewhere.

When I compiled the program, my QT libraries were on the way /media/free/QT/5.5, and now the snap package for some reason is looking in the same place.

I would be grateful for the help.

@willcooke Any idea of who might help Alexey here?

In fact, I have been trying to figure this out for a long time now, how and where to set the path to the libraries correctly so that the application knows and finds them in the snap.
I wrote in snapcraft.yaml

apps:
    BSP095launcherCoreSimulation:
        command: bin/run.sh $SNAP/bin/start_CORE_simulation.sh
        plugs: ['home', 'x11', 'opengl', 'gsettings', 'raw-usb', 'serial-port', 'network']
        environment:
            LD_LIBRARY_PATH: $SNAP/QT:$LD_LIBRARY_PATH

doesn’t work

I wrote in run.sh file what was generated by the snapcraft itself and had the form desktop-launch

# XKB config
export XKB_CONFIG_ROOT=$RUNTIME/usr/share/X11/xkb

# Give XOpenIM a chance to locate locale data.
# This is required for text input to work in SDL2 games.
export XLOCALEDIR=$RUNTIME/usr/share/X11/locale

# Mesa Libs for OpenGL support
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$RUNTIME/usr/lib/$ARCH/mesa
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$RUNTIME/usr/lib/$ARCH/mesa-egl

#setting for app. Here are the QT libraries for the program
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$SNAP/QT

Maybe I’m doing something wrong?

You say that you’re getting error messages referencing the path /media/free/QT/5.5. Could you post those actual error messages? It would make it a bit easier to help diagnose what is going on.

It is possible that your app has been linked using a -rpath option that causes it to search in that location, but that shouldn’t stop LD_LIBRARY_PATH from functioning (I think).

This is just a stab in the dark (because I don’t know what the error message is), but is it possible that the error isn’t coming from the dynamic linker, and is instead some other piece of code that is searching for a plugin in that other location? That might require some other environment variable to be set to change where it searches.

There is no talk of an error.
When I was build the project, all the QT library were on the way /media/free/QT/5.5.
And now when the binary is in a snap and I set it where to find the libraries it needs ($SNAP/QT), it still follows the build paths in the system /media/free/QT/5.5.

Or other project try to find libraries QT in like in system folder $SNAP/usr/lib/x86_64-linux-gnu
For this project, I set it where to look for libraries (like the first project, $SNAP/QT)

@jamesh Can you advise something?