pycairo failing appimage build

[mayli]

Describe the bug

The -fdebug-default-version=4 seems to an options for clang, but not gcc. Not sure why pycairo panic on that.

Docker|       Building wheels for collected packages: pycairo
Docker|         Building wheel for pycairo (pyproject.toml): started
Docker|         Building wheel for pycairo (pyproject.toml): finished with status 'error'
Docker|         error: subprocess-exited-with-error
Docker|
Docker|         × Building wheel for pycairo (pyproject.toml) did not run successfully.
Docker|         │ exit code: 1
Docker|         ╰─> [16 lines of output]
Docker|             running bdist_wheel
Docker|             running build
Docker|             running build_py
Docker|             creating build
Docker|             creating build/lib.linux-x86_64-cpython-311
Docker|             creating build/lib.linux-x86_64-cpython-311/cairo
Docker|             copying cairo/__init__.py -> build/lib.linux-x86_64-cpython-311/cairo
Docker|             copying cairo/__init__.pyi -> build/lib.linux-x86_64-cpython-311/cairo
Docker|             copying cairo/py.typed -> build/lib.linux-x86_64-cpython-311/cairo
Docker|             running build_ext
Docker|             building 'cairo._cairo' extension
Docker|             creating build/temp.linux-x86_64-cpython-311
Docker|             creating build/temp.linux-x86_64-cpython-311/cairo
Docker|             gcc -pthread -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv -O3 -Wall -fdebug-default-version=4 -fPIC -I/tools/deps/include -I/tools/deps/include/ncursesw -I/tools/deps/libedit/include -fPIC -DPYCAIRO_VERSION_MAJOR=1 -DPYCAIRO_VERSION_MINOR=25 -DPYCAIRO_VERSION_MICRO=0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng16 -I/usr/include/uuid "-I/app/Hello World.AppDir/usr/python/include/python3.11" -c cairo/bufferproxy.c -o build/temp.linux-x86_64-cpython-311/cairo/bufferproxy.o -Wall -Warray-bounds -Wcast-align -Wconversion -Wextra -Wformat=2 -Wformat-nonliteral -Wformat-security -Wimplicit-function-declaration -Winit-self -Winline -Wmissing-format-attribute -Wmissing-noreturn -Wnested-externs -Wold-style-definition -Wpacked -Wpointer-arith -Wreturn-type -Wshadow -Wsign-compare -Wstrict-aliasing -Wundef -Wunused-but-set-variable -Wswitch-default -Wno-missing-field-initializers -Wno-unused-parameter -Wno-unused-command-line-argument -fno-strict-aliasing -fvisibility=hidden -std=c99
Docker|             gcc: error: unrecognized command-line option ‘-fdebug-default-version=4’
Docker|             error: command '/opt/rh/gcc-toolset-12/root/usr/bin/gcc' failed with exit code 1
Docker|             [end of output]
Docker|
Docker|         note: This error originates from a subprocess, and is likely not a problem with pip.
Docker|         ERROR: Failed building wheel for pycairo
Docker|       Failed to build pycairo
Docker|       ERROR: Could not build wheels for pycairo, which is required to install pyproject.toml-based projects

Steps to reproduce

1. Follow the tutorial
2. briefcase create linux appimage
3. See error

Expected behavior

Build the image.

Screenshots

No response

Environment

• Operating System: ubuntu1~23.04
• Python version: 3.11
• Software versions:
  • Briefcase: 0.3.16
  • Toga: 0.3.1

Logs

Additional context

No response

[rmartin16]

I haven't tracked back the root cause to understand this for myself yet...but this was addressed for Flatpak:

beeware/briefcase-linux-flatpak-template@dd1ad51?diff=unified&w=0

But even if you do those transformations for AppImage, you run in to why we had to lower our support for AppImage with Briefcase v0.3.16:

• Deprecate AppImage to 'best effort' support. #1449.

As is laid out in that PR and related issues, the recent changes to PyGObject require a quite recent version of glib....but the whole premise of AppImage is building with older libraries for compatibility. So, for the time being, you can theoretically build AppImages using Briefcase and Toga on a sufficiently new-enough distro.....but the portability of that AppImage will likely be compromised.

[rmartin16]

In terms of restoring what you had before, this should work:

Update pyproject.toml:

• Add support_revision = "3.11.5+20230826" to your linux.appimage section
• Pin package PyGObject==3.44.1

[freakboy3742]

As an alternative to specifying the support revision - modify the Dockerfile to install clang, rather than work around the problem.

I've pushed a template branch that does this; if you add template_branch = "appimage-clang" to the appimage section of your pyproject.toml and re-run create, that should pick up the fix. You'll still need to pin PyGobject, or you'll get an error about a glib-2.0 version problem with PyGObject is built.

If someone can confirm this works for them, I'll backport this to the 0.3.16 template.

It's also worth noting that the pining fix will only work with Toga <= 0.3.1. The next release of Toga requires a bug fix in PyGObject 3.46.0, so you can't satisfy the PyGObject and GlibC requirement on any published manylinux release.

[rmartin16]

We have resolved this error:

gcc: error: unrecognized command-line option ‘-fdebug-default-version=4’

via beeware/briefcase-linux-appimage-template#40.

Until a new release is made for Python 3.12 from python-build-standalone, this fix only applies to Python 3.11 and older.

Re-running briefcase create linux appimage will pull down the updates for your app build. Explicitly setting support_revision is no longer necessary.

And to reiterate, unless you use a much newer Docker base image than the default manylinux2014, you will need to pin PyGObject==3.44.1 and toga-gtk==0.3.1.