Snapcraft build g++ not work on fedroa 39

snapcraft
1

snapcraft build g++ not work on fedroa 39

sudo snapcraft --destructive-mode --enable-experimental-extensions

return error

2024-01-29 17:46:08.241 :: checking whether the C++ compiler works… no 2024-01-29 17:46:08.243 :: configure: error: C++ compiler cannot create executables 2024-01-29 17:46:08.243 :: See `config.log’ for more details

my snapcraft.yaml

name: desmume
version: 0.9.11
summary: DeSmuME is a Nintendo DS Emulator
description: |
  An open-source Nintendo DS Emulators.

adopt-info: desmume
grade: stable
confinement: strict
base: core22
parts:
  desmume:
    source: http://archive.ubuntu.com/ubuntu/pool/universe/d/desmume/desmume_0.9.11.orig.tar.gz
    #override-pull: |
    #  snapcraftctl pull
    #  last_commit="$(git describe | sed 's/^v//; s/-.*-/-/')"
    #  snapcraftctl set-version "${last_commit}"
    #  #sed -i.bak -e 's|Icon=desmume|Icon=/usr/share/icons/hicolor/scalable/apps/desmume.svg|g' src/wx/desmume.desktop
    plugin: autotools
    stage-packages:
      - libsdl2-2.0-0
      - libsfml-network2.5
      - libsfml-system2.5
      - libnotify4
      - libsm6
      - libopenal1
      - libpng16-16
      - libpulse0
      - zlib1g
      - libgtk-3-0
      - libgl1
      - libglvnd0
      - libglx0
      - libopengl0
      - libasound2
      - libwxgtk3.0-gtk3-0v5
      - libc6
      - libgcc-s1
      - libgl1
      - libglib2.0-0
      - libglu1-mesa
      - libsdl1.2debian
      - libsoundtouch1
      - libstdc++6
      - libtinyxml2.6.2v5
      - zlib1g
      - g++
      - gcc
      - gettext
      - make
      - cmake
      - nasm
      - pkg-config
      - git
      - zip
      - libnotify-dev
      - libsdl2-dev
      - libsfml-dev
      - libgtk-3-dev
      - libopenal-dev
      - libwxgtk3.0-gtk3-dev
      - libglib2.0-dev
      - libsdl1.2-dev
      - libosmesa6-dev
      - libagg2-dev
      - intltool
      - libtinyxml-dev
      - libsoundtouch-dev
    build-packages:
      - g++
      - gcc
      - gettext
      - make
      - cmake
      - nasm
      - pkg-config
      - git
      - zip
      - libnotify-dev
      - libsdl2-dev
      - libsfml-dev
      - libgtk-3-dev
      - libopenal-dev
      - libwxgtk3.0-gtk3-dev
      - libglib2.0-dev
      - libsdl1.2-dev
      - libosmesa6-dev
      - libagg2-dev
      - intltool
      - libtinyxml-dev
      - libsoundtouch-dev

apps:
  desmume:
    plugs:
      - desktop
      - desktop-legacy
      - audio-playback
      - opengl
      - joystick
      - raw-usb
      - screen-inhibit-control
      - home
      - removable-media
      - network
      - wayland
      - x11
    command: usr/games/desmume-cli
    desktop: usr/share/applications/desmume.desktop
    extensions: [gnome]
    environment:
      LD_LIBRARY_PATH: $LD_LIBRARY_PATH:$SNAP/usr/lib/$SNAPCRAFT_ARCH_TRIPLET/pulseaudio

please help to solve

2

In these situations I’d always recommend starting from scratch.

Packages like GCC are implicit when using the gnome extension, as are others like libgtk, libpng, libpulse, libglu1-mesa, etc. There’s no need to explicitly mention them in either stage or build packages, and when you do, you run the risk of mixing incompatible libraries because the GTK3 in the Ubuntu repositories is not the same GTK3 in the Gnome snap, whilst there’s some safeguards to prevent these problems, it still results in a bigger snap package and ergo slower loading snap package for no benefit.

Try starting your package lists from scratch and then satisfying dependencies one at a time in a targetted manner. Whilst there’s not a huge downside to having libsdl1 and libsdl2, there’s probably no need to have both.

This will probably half the size of your Snapcraft file and is a much easier starting position for ourselves and yourself to work from.

I always like to show one of my own Snaps as an example because it illustrates the point very well. Pinta is a GTK3 (soon GTK4) based app. The GTK4 port doesn’t change a single line apart from the source-commit, because the vast majority of common desktop packages are implicit in gnome or it’s equivilent QT/KDE extensions.

https://github.com/MrCarroll/pinta-snap/blob/master/snap/snapcraft.yaml

The only package mentioned in that file is for the runtime is .NET, but the Snap absolutely still has GL drivers, sound support, GTK itself, etc. Meanwhile, the build packages are only the absolute bare minimum packages Gnome doesn’t make explicit that it happens to need, and as I look at it right now, I’d bet I could even drop the build-essential.

Finally, you shouldn’t be running in destructive mode at all in this situation, and especially not on Fedora. Destructive mode is meant for ephemeral virtual machines or containers, and where the OS matches the base. It’s not supported to use any non Ubuntu distribution in destructive mode. Try either installing the LXD snap and using the LXD backend, or using the remote build service to do it on Canonicals build farm instead. You will never get a working snap in destructive mode on a non-Ubuntu distro.

The likelyhood is that running in destructive mode, as the name implies, has probably trashed your Fedora installation in weird ways that would only likely ever be fixed by a full reinstallation. LXD is the default to prevent this. In my personal opinion, I’d back up any data you have and reinstall Fedora before going on with anymore snap tasks, because it’s quite likely your system could break at reboot, future package upgrades, or future release upgrades.

1 Like
3

You shouldn’t use --destructive-mode on any non-ubuntu system, it will definitely break

1 Like
4

Destructive mode – AFAIR – uses the host. Here you will be mixing binaries referenced by snapcraft with binaries from your Fedora system - the combination is not compatible.

You must either use virtualization or containers for this to work.