search

Xpra-org / gtk-osx-build

Build setup to help building the Mac OS X port of GTK+
http://gtk-osx.sourceforge.net/
0 stars 2 forks source link

errors when starting from scratch #25

Closed totaam closed 1 year ago

totaam commented 1 year ago
totaam commented 1 year ago

Now also hitting #21 from a plain jhbuild shell with python -c from gi.repository import Pango. Same problem importing the Gtk / Gdk bindings but not GLib. Unlike #21, there is a useful error message: Failed to load shared library libpango-1.0.0.dylib ... image not found

Somehow the environment / python is not configured to look in $JHBUILD_LIBDIR?

totaam commented 1 year ago

Also, pyobjc 9.0.1 bd4fcc2188ace8eff8392b7f0e08211f2ae3a341 segfaults on import... So does 8.3 onwards. Reverted in b8843a34760a03dce3389c2b6b19a4d9eb0c0588.

totaam commented 1 year ago

And the never ending breakage from setuptools gets another episode: it breaks py2app between version 60.8.2 and 60.9.0... Downgraded in 4cac9061b3f40de773a60456f6318c46c60d5b56.

totaam commented 1 year ago
totaam commented 1 year ago

Being audacious (or reckless?), I merged yet more updates from upstream: b072ef2729fb26085c41032bddc52c49409eca9a followed by lots of library updates - which I will dutifully submit upstream.

Then I found that a bunch of bootstrap things were failing because of certificate errors: https://github.com/Xpra-org/xpra/commit/ba0b8eb39d75aeb2a6f389b77786588333e45841 And that Python can't be built because of yet more setuptools breakage: https://github.com/Xpra-org/xpra/commit/c19b116b3459bd5afe270458613d2ccd3a333232

Compiling from source prints «ModuleNotFoundError: No module named 'binascii'» - newer versions of setuptools fix this but we can't use them because they break something else! (py2app)

And during make install, Python fails - looks like another setuptools bug: Python installation fails to install pip3 if pip, setuptools in ~/.local - so I bypassed this for now using:

--- a/_distutils_hack/__init__.py   2023-02-19 23:21:40.000000000 +0700
+++ b/_distutils_hack/__init__.py   2023-02-19 23:22:26.000000000 +0700
@@ -114,7 +114,7 @@
         import traceback
         return any(
             frame.f_globals['__file__'].endswith('setup.py')
-            for frame, line in traceback.walk_stack(None)
+            for frame, line in traceback.walk_stack(None) if '__file__' in frame.f_globals
         )

We still have 3 packages that should be installed using pip rather than setuptools (they're missing setup.py: pyparsing, typing_extensions and packaging. No idea how to do this using the jhbuild moduleset syntax

totaam commented 1 year ago

Then more errors, from you guessed it, setuptools as there is a conflict between the pyenv version and the one we ship in the jhbuild root.

typing_extensions, packaging and parsing need to be installed with pip3 but into the jhbuild prefix not pyenv!

unset PYTHONUSERBASE
unset PYENV_ROOT
unset VIRTUAL_ENV
#also remove pyenv from PATH and LDFLAGS?
pip3 install setuptools==60.8.2 --prefix $JHBUILD_PREFIX
pip3 install typing_extensions --prefix $JHBUILD_PREFIX
pip3 install packaging --prefix $JHBUILD_PREFIX
pip3 install parsing --prefix $JHBUILD_PREFIX

This needs to be automated. Even more variables need to be sanitized when running the ./make-app.sh script.

Also, we need the git version of https://github.com/GNOME/gtk-mac-bundler for python3 support.

And we need to switch back to turbojpeg... with or without fixing #19

totaam commented 1 year ago

As it stands, it's almost usable again, except:

totaam commented 1 year ago

The build instructions have been updated for the pip3 packages: https://github.com/Xpra-org/xpra/commit/8ba0f87ad966f95656e2b36a5adb1950ef35a73f.

Only leaves other tickets:

And more updates to send upstream: libpng 1.6.39 76c35469823a5e184c185c1326161e37e9a70457, gstreamer 1.22.0 46fdaa01566ac878deb8a265bed3c5790fec54d7.

We now have 5.0-r32737 beta builds here: https://xpra.org/beta/MacOS/

Now onto another problem: https://github.com/Xpra-org/xpra/issues/3765

totaam commented 1 year ago

The last remaining blocked was caused by pyobjc, downgrading to version 8.2 fixes that. See also #26 and #22.

totaam commented 1 year ago

Also, libbrotli*.dylib don't use the full path for their dylib references and when rebuilding freetype these then get picked up... causing other failures down the line, ie: gobject-introspection. Solved the dirty way: rm -fr $JHBUILD_PREFIX/lib/libbrotli*;jhbuild buildone -f freetype;jhbuild build