Need Some Help?

Hey there, i need some help packaging audacious-snap, the snap has been built successfully but audacious has a core component audacious plugins available as a separate source package, i have successfully added it as another part in YAML, but the ./configure of it option needs audacious already installed, how do i achieve this in a single snapcraft yaml ?? Here is my YAML --:

You can declare after: [audacious] in the plugins parts, so that Audacious will be built and staged in $CRAFT_STAGE before the plugins part is built. You may need to adjust some build options in the plugins part to look for the application in the staging area.

1 Like

thanks for replying,will using --> ./configure --enable-gtk3 --disable-qt --PKG_CONFIG_PATH=$PKG_CONFIG_PATH:$CRAFT_STAGE ??, work

Snapcraft already sets PKG_CONFIG_PATH to some standard locations so it may just work without having to set it manually. Otherwise you can change it accordingly, or see if there are options to the configure script that can help to tweak development component locations. (Note that PKG_CONFIG_PATH is an environment variable and not an option to the configure script.)

Hey there as you said, snapcraft has automatically fixed such issues and audacious plugins have been successfully built but when running the snap it cant detect and use the audacious plugins and libs it always gives the following error --:

‘’’ error while loading shared libraries: libaudcore.so.5 ‘’’

and if i try to violate sandbox by running the snap from the snap directory it says audacious plugins not found eventhough it has been successfully packaged along audcore in snap/audacious-snap/usr/lib, how do i make audacious use these libraries and read them properly ?

Hey there,The New problem is that as per my findings the plugins part gets successfully buit and installed but not in the /usr of the first part instead it exists in a different directory and concerned subdirectories called build, that is to make the snap work i will have to get i installed in the /usr but its installed in /build, any solution ??..

If the shared libs are located in a nonstandard location inside the snap payload tree you’ll need to tell the linker where it should look for libraries at runtime (e.g. by setting the LD_LIBRARY_PATH in the app environment: entry). In my mpg123 snap I do something like this:

apps:
  mpg123:
    ...
    environment:
      LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/$CRAFT_ARCH_TRIPLET/pulseaudio
      MPG123_MODDIR: $SNAP/lib/mpg123

Note that if the plugins themselves are not found you need to tell the application where the plugins are. These are typically dlopened there could be an application-specific way to configure that.

Files that will be part of the final snap should exist in the prime directory. One part won’t write files to the build or install directory of another part, but they should all be consolidated in the stage directory, and later in prime after filters are applied (if any).

If something exists in the part’s build directory but not in the part’s install directory, you need to install it if you want it to be inside the final snap. This is usually done as part of the package’s normal make install process in the build step.

thanks for the reply,the problem being is that all the things needed to install are already installed but the components like output etc. are left out in the build directory, audacious part is installed with a executable but the libraries are not in the /usr directory, even if i specify it properly, it remains in the build directory

Here is the screenshot of contents of the directory, there is nothing that can be installed with make etc.

Ah, that’s odd, you ended up with the build directory inside the final snap payload! Could you post the current yaml you’re using so we can see what’s happening there?

Ok,

I have recently changed the wrong executable path to /usr/bin/audacious wont affect the rest of the snap

You’re doing a couple of strange things there: in both parts you already declared the git repository as the part’s source, so you don’t need to clone it manually in override-pull. You also don’t need to do things manually in override-build if you use the autotools plugin instead of the nil plugin. Custom configuration options can be declared as autotools-configure-parameters.

It’s not immediately obvious to me why a “build” directory appeared in the snap payload. I can try to build it locally later today to see what’s happening there, but in the meantime using the autotools plugin and removing manual git cloning can make things easier.

bit more details in adding parameters to autotools please ??, got it, i will implent your suggestions, thanks

This is what I do in my mpg123 snap:

parts:
  mpg123:
    plugin: autotools
    source: ...
    autotools-configure-parameters:
      - --prefix=
      - --with-default-audio=pulse
      - --enable-network=yes
      - --enable-ipv6=yes
    ....
1 Like

thanks :smiling_face_with_three_hearts:

After all your implementations its still broken…

What’s causing the plugins to be installed under a weird path is the staged audacious pkgconfig file, audacious.pc. Snapcraft patches the file to point to the correct build time locations under stage, but audacious also uses it to set the runtime directory for plugins. To address that, we can for example change plugins_dir back to something more reasonable:

parts:
  audacious-snap:
    source: https://github.com/audacious-media-player/audacious.git
    plugin: autotools
    ....
    override-stage: |
      craftctl default
      sed -i -e '/^plugin_dir=/s/\${exec_prefix}/\/usr/' usr/lib/pkgconfig/audacious.pc

This should fix the plugin location inside the snap (so there will be no /root/stage paths there), but you still need to find a way to tell audacious where to find the plugins – you could use an environment variable (if it exists), or use a layout entry to point /usr/lib/audacious to $SNAP/usr/lib/audacious.

(It’s also interesting that your example also triggered @bugraaydogar’s version setting bug and I finally found a simple way to reproduce it!)

Thanks for checking out, i will implement your suggestions, meantime also thanks to clear my doubt regarding layouts i thought they are only used for connecting to external system folders etc. but glad to know we can also do internally, i will create a symlink for the current use…