Open sammirata opened 1 year ago
Just wanted to update that there has been some progress this week-end. I was able to rebuild the environment and got that to work with GitHub Actions as well. Also was able to grab and build WhiteSur icon & gtk theme locally (still failing on GitHub Actions). I'll try to get the theme to work on GH actions during the week. You can view the Actions tab to see the output. We're almost halfway through! I'm hoping to get the themes fully working on GH actions by tomorrow.
Credits WhiteSur and WhiteSur-icon-theme
Locally and on my environment, I can run meld without the packaging part using this new environment and theme(s). Which is pretty good news that we're on the right track. This leaves us with packaging the dmg itself (which is another big script, but I'm hoping that there aren't big changes). Hopefully next week-end.
This may also be the solution to finally being able to produce m1/m2 builds as I understand that GitHub is now offering public beta runners for the arch. My wife has an m1 laptop, but I'm not excited about building on it due to the sheer size of the packages that we have to build and I'm not excited about having to cross compile or to generate universal binaries with jhbuild either. I already tried. It's not straightforward at the moment.
I hope that I would be able to finish this quickly because I want to focus on my other project (https://github.com/yousseb/atfal-ai & https://github.com/yousseb/atfal-site) which is an effort to track missing children/people and use AI to help find them. I love meld, but as a person who has lost his brother in a way that he couldn't come back - and I keep losing family in Gaza -, I want to help reunite families who still have the chance to be reunited. Everyone is welcome to help.
Unlucky timing, I'm coming here from this upstream issue https://gitlab.gnome.org/GNOME/meld/-/issues/804 where I have begun creating a macOS app for Meld. Once I'm happy with it I'm going to propose this to become the official macOS release of Meld - at least that was the plan before I noticed that there's new activity here. I am not interested in creating a competing port and would stop doing what I'm doing, but given the fact that you're planning to shift focus to other things anyway, you might want me not to. Let me know what you think.
@dehesselle I just saw your screenshot on the issue. It is awesome and well done indeed! I'm planning to get this port to work again - and hopefully if we get m1 runners to provide an m1 build. When I first started this port, there was no CI on github and I built everything on slow laptops with the following intentions in mind:
I even went ahead and added 'signing capabilities' but I ended up not getting the keys from the Apple developer program due to the fact that I moved countries and the Apple developer program was not accepting my credit card any longer since it tied my registration to the original country where I signed up.. Needed a lot of bureaucracy and paperwork which I didn't have the time/patience to do..
I'm hoping that with CI, people would be able to fork and fix help fix issues. Perhaps you could help with that when this fork eventually - and surely - breaks again? :)
I usually don't touch upstream code outside of what I need for packaging (e.g. to make an app relocatable). My focus is on the build pipeline; I have a specific JHBuild-based setup that I'm using across multiple projects so I can handle the maintenance burden, including dependency management, CI for Intel/ARM and signing/notarization of releaes. But this work takes place mostly on GitLab because I have build infrastructure there and generally prefer their CI.
Out of curiosity, have you tried upstreaming your macOS look & feel changes? Or do you prefer to stay in your fork (which is fine)?
@dehesselle I have used both GitLab CI and GitHub Actions. They'll both get the job done, so no worries there. Curious: Could you share some links to the part you're doing ARM?
re have you tried upstreaming your macOS look & feel changes: Some that made sense to go upstream (shortcuts, etc). However, the main blocking point for me was that there was a homebrew and "mac ports" versions of meld that mainly relied on gtk/xorg for macOS when this project came out with no way of cleanly differentiating between the gtk/xorg build and the native gtk build. I didn't bother much to be honest then.
However, and now that you mention it, Kai and the rest of the upstream meld developers and maintainers are super nice and helpful guys. Maybe I will talk to them about guidance and see if we can get a plan to implement that. I could keep the fork just synced for the build automation but have the changes merged in upstream to reduce the work whenever a release comes out.
Yes, you can look at the work that I have done so far before I came here: https://gitlab.com/dehesselle/meld_macos
@canhascodez thank you for your tip.
To simply start without building it was enough to run the first two commands (cmake
and meson
are not needed in this case):
pip3 install pyobjc
brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3
and then I was able even to start meld
from the upstream
git clone https://gitlab.gnome.org/GNOME/meld.git
meld/bin/meld
Tested only on M1 architecture.
@canhascodez thank you for your tip.
To simply start without building it was enough to run the first two commands (
cmake
andmeson
are not needed in this case):pip3 install pyobjc brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3
and then I was able even to start
meld
from the upstreamgit clone https://gitlab.gnome.org/GNOME/meld.git meld/bin/meld
Tested only on M1 architecture.
You can also just run @yousseb's version, without cloning the upstream, by following the first part of @devqore's / @canhascodez's instructions:
pip3 install pyobjc
brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3
then:
/Applications/Meld.app/Contents/MacOS/Meld
from the terminal, launching through Finder won't work.
Ignore this - it worked once, now, back to segfault-ing on launch, stick with the source pull!
I tried @devqore's suggestion of installing the dependencies via brew
, then running meld
from the upstream. However, it doesn't work for me:
# ./bin/meld
2023-10-30 09:23:01,408 INFO Gtk: GLib-GIO-Message: 09:23:01.407: Adding GResources overlay '/org/gnome/meld=/Users/georgevulov1/dev/external/meld/meld/resources'
Namespace GtkosxApplication not available
Traceback (most recent call last):
File "/Users/georgevulov1/dev/external/meld/./bin/meld", line 517, in <module>
sys.exit(main())
^^^^^^
File "/Users/georgevulov1/dev/external/meld/./bin/meld", line 513, in main
return run_application()
^^^^^^^^^^^^^^^^^
File "/Users/georgevulov1/dev/external/meld/./bin/meld", line 494, in run_application
app = MeldApp()
^^^^^^^^^
File "/Users/georgevulov1/dev/external/meld/meld/meldapp.py", line 57, in __init__
GtkosxApplication.Application.__init__(self)
^^^^^^^^^^^^^^^^^
NameError: name 'GtkosxApplication' is not defined
Not sure which dependency is supposed to provide GtkosxApplication
.
gtk-mac-integration
provides GtkosxApplication
.
@dehesselle Thank you! Got meld running locally now. To summarize:
pip3 install pyobjc
brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3 gtk-mac-integration
Then,
git clone https://gitlab.gnome.org/GNOME/meld.git
./meld/bin/meld
It seems to be much snappier than this port of meld -- scrolling through a large diff is smoother and less laggy.
It seems to be much snappier than this port of meld -- scrolling through a large diff is smoother and less laggy.
That's because of updated dependencies. There have been significant improvements to GTK and Cairo since the last release of "Meld for OSX".
After performing the above:
$ pip3 install pyobjc
# lots of console spam, no errors.
$ brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3 gtk-mac-integration
# lots of console spam, no errors.
$ git clone https://gitlab.gnome.org/GNOME/meld.git
Cloning into 'meld'...
# etc...
$ ./meld/bin/meld
Couldn't bind the translation domain. Some translations won't work.
module 'locale' has no attribute 'bindtextdomain'
Meld requires Gtk+ 3.22.
DEPRECATION WARNING: The system version of Tk is deprecated and may be removed in a future release. Please don't rely on it. Set TK_SILENCE_DEPRECATION=1 to suppress this warning.
...but I already have gtk+-3.24.38 installed by brew.
This is on a 2021 M1 MacBook Pro.
TurboEncabulator9000, had the identical issue. For me it was a system python and a homebrew python that are different. Don't ask me how to set these up to consistently to use all of the correct site packages, but I suggest brew info python
and just use whatever python path it tells you.
For testing purposes, run
<where_is_your_homebrew>/bin/python3 <where_is_your_meld>/bin/meld
to force the usage of your Homebrew Python.
Thanks for the advice! It does work if I put /opt/homebrew/bin
first in my .bash_profile
$PATH
variable. However, the window is hiding under other windows, so I have to go find it and move it to a screen with empty space available.
However:
You are running meld directly from upstream source where the UI/UX customizations that were developed here are absent.
combining answers from above, this worked ok for me, app is working from cmd line run start:
"
pip3 install pyobjc
brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3 gtk-mac-integration
brew install python3
git clone https://gitlab.gnome.org/GNOME/meld.git
/opt/homebrew/bin/python3 ./meld/bin/meld
"
enjoy :)
attempting comment Nov 1, 2023
funny graphical glitch (clicking the dock icon that says python instead of meld restores it)
looks to be working:
I haven't tested folders or a merge conflict yet. Looking good so far.
I've got this bash script in my ~/bin/meld
(which is in my PATH):
#!/bin/bash
set -e # halt on error
set -x # echo cmds before executing
set -u # fail on undefined variable
set -o pipefail # force pipelines to fail on fail
/opt/homebrew/bin/python3 /Users/$USER/code/meld-build/meld/bin/meld $@
so now meld left_file.cr right_rile.cr
works in new bash/fish sessions.
Are we going to get a proper package in the near future? Fingers crossed.
@alexolog Yes. It has taken me 2 full weekends thus far to prepare the environment that will be packaged, but it's not done yet. I'm having to rebuild again for issues with the internationalization libs - which we're not even using, but it's a dependency. I'm expecting at least this weekend, too.
Awesome, looking forward to it!
Take your time, and thank you for working on it!
combining answers from above, this worked ok for me, app is working from cmd line run start:
"
pip3 install pyobjc brew install gtk+3 gtksourceview4 gnome-icon-theme desktop-file-utils itstool py3cairo pygobject3 gtk-mac-integration brew install python3 git clone https://gitlab.gnome.org/GNOME/meld.git /opt/homebrew/bin/python3 ./meld/bin/meld
"
enjoy :)
I tried this solution but getting this error
python3 ./meld/bin/meld
Couldn't bind the translation domain. Some translations won't work.
module 'locale' has no attribute 'bindtextdomain'
Meld requires Gtk+ 3.22.
Anyone else got this? meld was my diff client choice in linux but now that I am developing in a mac I just cannot find a decent alternative.
Anyone else got this? meld was my diff client choice in linux but now that I am developing in a mac I just cannot find a decent alternative.
Yes, I have the same on my hackintosh. On my M1 mac it does work 🤔
Edit: found the solution: I have several python3 versions installed (3.9, 3.10, 3.12). When invoked like /usr/local/bin/python3.12 meld/bin/meld
it works!
@everyone I finally have a successful build. Actually had one since yesterday morning and have spent the whole day yesterday and a good two hours this morning tinkering with GitHub Actions to fix the CI and be able to release from it. I didn't test beyond seeing the app window open up. This one works! https://github.com/yousseb/meld/actions/runs/6772677687
I'll upload the release after finishing the work day. I'll cleanup and fix any messy shortcuts that I did later this weekend. So whatever I upload today should not really be packaged to homebrew. It is just for getting the app up and running.
I hope that I'll be able to make an m1 build on GH later this week too. No promises though as I haven't read any docs on how to do this yet.
NOTE: This build will not include any new features (same source code for Meld) - except the new theme/icons and using the latest underlying libraries.
Thank you guys for your patience. I would appreciate if you can help me test this one so that if there are issues that I could fix, I would try and fix them this coming weekend.
Thank you @yousseb ! Is this runnable on M1? I am getting the following error when trying to run: You can’t open the application “Meld.app” because this application is not supported on this Mac.
.
@matthiasdiener This one is compiled for x64 arch. It "should?" run with Rosetta 2, but I haven't tried it since my main macOS is still an older 2019 Intel.
I have this note above (GH = GitHub Actions which promises m1 runners):
I hope that I'll be able to make an m1 build on GH later this week too. No promises though as I haven't read any docs on how to do this yet.
Thank you, @yousseb . I'm having the same message as above, You can’t open the application “Meld.app” because this application is not supported on this Mac.
, when trying to run the application on an M1. Also, the application icon has a "forbidden" sign over it, even before installing.
I think it should have run under Rosetta and the issue is different. The older version (3.21.0.osx3 - Catalina) displays a different message: it says the developer isn't signed (which can be bypassed by right-click + Open) and then the app starts for a split second, before crashing. So in terms on MacOS, the older app is allowed and it doesn't throw the same message as the latest version - but of course it crashes after a split second and cannot be used. For me it doesn't seem to be a limitation of the OS, it seems the newer version is missing something that allowed the old one to run under Rosetta (??).
Darn, I was excited to see a new release, but unfortunately same problem on M2 Pro. But thanks for all the effort you're putting in!
@yousseb Happy to say that https://github.com/yousseb/meld/releases/tag/osx-20 seems to work fine on Intel-based mac running 14.0 (23A344).
Tested comparing files and dirs, both seem to work without issues. Many thanks for your time and dedication in getting it run again!
I can also confirm that this new build works on my Macbook Pro 2019 running 14.1 (23B74)
I did have an issue with it being unsigned initially due to my machine being fairly locked down, but I managed to overcome that
But I do see a deprecation warning in the console on launch:
/Applications/Meld.app/Contents/Resources/__boot__.py:118: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
2023-11-07 10:15:22,239 CRITICAL Gtk: gtk_window_add_accel_group: assertion 'GTK_IS_WINDOW (window)' failed
Thank you guys for your patience. I would appreciate if you can help me test this one so that if there are issues that I could fix, I would try and fix them this coming weekend. https://github.com/yousseb/meld/releases/tag/osx-20
It is not supported on my M2 macbook.
M1 Pro too. :( Impatietly waiting for. :)
Yeah, unfortunately it does not work in M1/M2. For some reasson Rosetta is not able to launch it ....
intel vs arm: It looks like m1/2/3 is the current urgent task. I'll focus on this and try to get it working. Looks like the m1 runners are only available as paid runners. I'll cover the cost for this round.
@alicekaerast Signing: This will take a while. Apple is quite bureaucratic and my account is still attached to a different country. Deprecation/critical log: You get this when starting from the command line, right?
Deprecation/critical log: You get this when starting from the command line, right?
Yes that's correct, either running from the previously created Homebrew wrapper/symlink /usr/local/bin/meld -> /usr/local/Caskroom/meld/3.21.0-r3,19/meld.wrapper.sh
or from the included /Applications/Meld.app/Contents/MacOS/Meld
To be clear, Meld works, it just prints out those log lines when I run it from the CLI
Works on Intel Mac 13.6 (22G120) ✅. TY
intel vs arm: It looks like m1/2/3 is the current urgent task. I'll focus on this and try to get it working. Looks like the m1 runners are only available as paid runners. I'll cover the cost for this round.
Let me know if I can help with something. I'm happy to build and test it locally if you like. Thanks again!
@matthiasdiener Thank you! All the steps are here: https://github.com/yousseb/meld/blob/master/.github/workflows/main.yml This package that I uploaded for x64 was fully generated from this file.
Note: You would need to change setup.cfg
https://github.com/yousseb/meld/blob/master/setup.cfg#L3
arch should be in this list: https://py2app.readthedocs.io/en/stable/options.html?highlight=arch#option-reference
I'm still not clear as to which it will be - arm/m1 not being in the list - so I'm guessing it will be universal
or universal2
, but jhbuild
does not provide either directly. I experimented with building an environment that is universal. It is feasible, but it will take a significant amount of work.
So - let's hope that it py2app
will take univeral
or universal2
and just provide m1.
PS: Building the environment is not fun. It is super slow. If you decide to do it, be patient! :) Look at the time this took when a prebuilt-cache from pervious jobs was not found: https://github.com/yousseb/meld/actions/runs/6757833844/job/18368770549
Hi,
Thanks for the update. But I got this when opening the app:
I'm using a 2020 Intel iMac with the latest MacOS.
FWIW I tried editing the Contents/Info.plist
to change
<key>LSRequiresNativeExecution</key>
<true/>
to <false/>
That removed the no entry badge over the icon on my M2 MBA running 14.1. But then I got the same Launch Error message as the previous comment.
@droplinxuser This one is hard to figure out - would you mind providing some more log?
python
interpreter next to the Meld
executable in the package. Does that python
interpreter start on its own?I have it now.
/Applications/Meld.app/Contents/MacOS/Meld
/Applications/Meld.app/Contents/Resources/__boot__.py:118: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
** (process:3476): WARNING **: 02:29:23.413: Failed to load shared library '@executable_path/../Frameworks/libpango-1.0.0.dylib' referenced by the typelib: dlopen(@executable_path/../Frameworks/libpango-1.0.0.dylib, 0x0009): Library not loaded: /usr/local/opt/libpng/lib/libpng16.16.dylib
Referenced from: <711B2F08-3C0C-30F5-B5A2-F9B163EC8824> /Applications/Meld.app/Contents/Frameworks/libfreetype.6.20.0.dylib
Reason: tried: '/usr/local/opt/libpng/lib/libpng16.16.dylib' (no such file), '/System/Volumes/Preboot/Cryptexes/OS/usr/local/opt/libpng/lib/libpng16.16.dylib' (no such file), '/usr/local/opt/libpng/lib/libpng16.16.dylib' (no such file), '/usr/local/lib/libpng16.16.dylib' (no such file), '/usr/lib/libpng16.16.dylib' (no such file, not in dyld cache)
Traceback (most recent call last):
File "/Applications/Meld.app/Contents/Resources/__boot__.py", line 163, in <module>
_run()
File "/Applications/Meld.app/Contents/Resources/__boot__.py", line 86, in _run
exec(compile(source, path, "exec"), globals(), globals())
File "/Applications/Meld.app/Contents/Resources/meld", line 517, in <module>
sys.exit(main())
^^^^^^
File "/Applications/Meld.app/Contents/Resources/meld", line 508, in main
check_requirements()
File "/Applications/Meld.app/Contents/Resources/meld", line 276, in check_requirements
r.check()
File "/Applications/Meld.app/Contents/Resources/meld", line 243, in check
mod = importlib.import_module(module)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "importlib/__init__.pyc", line 126, in import_module
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 674, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/importer.py", line 149, in load_module
importlib.import_module('gi.repository.' + dep.split("-")[0])
File "importlib/__init__.pyc", line 126, in import_module
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 674, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/importer.py", line 149, in load_module
importlib.import_module('gi.repository.' + dep.split("-")[0])
File "importlib/__init__.pyc", line 126, in import_module
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 674, in _load_unlocked
File "<frozen importlib._bootstrap>", line 634, in _load_backward_compatible
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/importer.py", line 150, in load_module
dynamic_module = load_overrides(introspection_module)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/overrides/__init__.py", line 118, in load_overrides
override_mod = importlib.import_module(override_package_name)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "importlib/__init__.pyc", line 126, in import_module
File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
File "<frozen importlib._bootstrap_external>", line 940, in exec_module
File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/overrides/Pango.py", line 41, in <module>
FontDescription = override(FontDescription)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Applications/Meld.app/Contents/Resources/lib/python3.11/gi/overrides/__init__.py", line 195, in override
assert g_type != TYPE_NONE
^^^^^^^^^^^^^^^^^^^
AssertionError
2023-11-08 02:29:23.480 Meld[3476:204379] Launch error
2023-11-08 02:29:23.480 Meld[3476:204379] Launch error
See the py2app website for debugging launch issues
Python binary works fine.
/Applications/Meld.app/Contents/MacOS/python
Python 3.11.4 (main, Nov 5 2023, 00:13:32) [Clang 14.0.0 (clang-1400.0.29.202)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
@droplinxuser This one is hard to figure out - would you mind providing some more log?
- Run from the command line - any logs there?
- There's a
python
interpreter next to theMeld
executable in the package. Does thatpython
interpreter start on its own?
I'm getting the same error as @droplinxuser with the same assert g_type != TYPE_NONE
error. Running Contents/MacOS/python
seems to run fine.
Trying to build using the CI instructions on M1 (MacOS 14.1), I got the following error while building ~gtk~ glib during build_env.sh
:
[1211/1470] Compiling C object gio/tests/defaultvalue.p/defaultvalue.c.o
FAILED: gio/tests/defaultvalue.p/defaultvalue.c.o
/usr/bin/clang -Igio/tests/defaultvalue.p -Igio/tests -I../../../../Source/gtk/glib-2.76.3/gio/tests -I. -I../../../../Source/gtk/glib-2.76.3 -Iglib -I../../../../Source/gtk/glib-2.76.3/glib -Igmodule -I../../../../Source/gtk/glib-2.76.3/gmodule -Igobject -I../../../../Source/gtk/glib-2.76.3/gobject -Igio -I../../../../Source/gtk/glib-2.76.3/gio -I/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include -I/Users/mdiener/gtk/inst/include -fcolor-diagnostics -DNDEBUG -fembed-bitcode -Wall -Winvalid-pch -Wextra -Wpedantic -std=gnu99 -O3 -D_GNU_SOURCE -fno-strict-aliasing -DG_DISABLE_CAST_CHECKS -Wimplicit-fallthrough -Wmisleading-indentation -Wmissing-field-initializers -Wnonnull -Wunused -Wno-unused-parameter -Wno-cast-function-type -Wno-pedantic -Wno-format-zero-length -Wno-variadic-macros -Werror=format=2 -Werror=init-self -Werror=missing-include-dirs -Werror=pointer-arith -Werror=unused-result -Wstrict-prototypes -Wno-bad-function-cast -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=pointer-sign -Wno-string-plus-int -O2 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -mmacosx-version-min=14 -arch arm64 -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk '-DG_LOG_DOMAIN="GLib-GIO"' '-DGLIB_MKENUMS="gobject/glib-mkenums"' '-DGLIB_COMPILE_SCHEMAS="/Users/mdiener/.cache/jhbuild/build/glib-2.76.3/gio/glib-compile-schemas"' -UG_DISABLE_ASSERT -MD -MQ gio/tests/defaultvalue.p/defaultvalue.c.o -MF gio/tests/defaultvalue.p/defaultvalue.c.o.d -o gio/tests/defaultvalue.p/defaultvalue.c.o -c ../../../../Source/gtk/glib-2.76.3/gio/tests/defaultvalue.c
In file included from ../../../../Source/gtk/glib-2.76.3/gio/tests/defaultvalue.c:178:
gio/tests/giotypefuncs.inc:169:9: error: call to undeclared function 'g_osx_app_info_get_type'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
*tp++ = g_osx_app_info_get_type ();
^
gio/tests/giotypefuncs.inc:169:9: note: did you mean 'g_app_info_get_type'?
../../../../Source/gtk/glib-2.76.3/gio/gappinfo.h:150:13: note: 'g_app_info_get_type' declared here
GType g_app_info_get_type (void) G_GNUC_CONST;
^
1 error generated.
Maybe the clang version is too new (Apple clang version 15.0.0 (clang-1500.0.40.1
)?
Came here to say that it launches ok but have not tried it much. intel mac sonoma 14.1
@droplinxuser
I see the issue.. Thanks for the report, I think I will be able to fix it.
pango
is linking to libpng
from homebrew instead of the bundled libpng
.
A quick workaround in your case would be to install libpng
from homebrew until I rebuild while fixing the link.
@matthiasdiener
Look here for the glib
compilation meson
args that I'm using.
https://github.com/yousseb/meld/blob/master/osx/jhbuildrc-custom#L111
Here are all the available meson
options for glib. Looks like it's failing while building tests. You can go ahead and disable building tests.
https://gitlab.gnome.org/GNOME/glib/-/blob/main/meson_options.txt?ref_type=heads#L80
add -Dtests=false
PS: If you're interested in seeing what others are doing for macOS, I'd recommend also looking at homebrew's build options. Here: https://github.com/Homebrew/homebrew-core/blob/50a6424c244848683d94674a17ded58cf6749c1e/Formula/g/glib.rb#L56 Then here: https://github.com/Homebrew/homebrew-core/blob/50a6424c244848683d94674a17ded58cf6749c1e/Formula/g/glib.rb#L76 (and more options down the file)
Thanks @yousseb ! With the changes in #148 , I was able to build and run meld on M1 natively! I've left a link to the built dmg in the PR in case someone wants to try it.
I upgraded my mac to sonoma and now the software crashes on startup. Here is the crash message:
Translated Report (Full Report Below)
Process: Meld [13083] Path: /Applications/Meld.app/Contents/MacOS/Meld Identifier: org.gnome.meld Version: 3.21.0.osx2 (3.21.0.osx2) Code Type: ARM-64 (Translated) Parent Process: launchd [1] User ID: 501
Date/Time: 2023-06-09 09:27:14.8923 -0400 OS Version: macOS 14.0 (23A5257q) Report Version: 12 Anonymous UUID: 24976634-5085-2C39-8A49-4462CB674113
Sleep/Wake UUID: BB6CB32F-0CE4-43D8-AC9B-A12741CB7AE9
Time Awake Since Boot: 62000 seconds Time Since Wake: 3052 seconds
System Integrity Protection: enabled
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000
Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x7ff89732aa78 ??? 1 libsystem_kernel.dylib 0x7ff8075ea88e pthread_kill + 10 2 libsystem_pthread.dylib 0x7ff807622f30 pthread_kill + 262 3 libsystem_c.dylib 0x7ff807542a71 abort + 126 4 libsystem_c.dylib 0x7ff807541d84 __assert_rtn + 314 5 libcairo.2.dylib 0x10df39aa3 _cairo_surface_release_source_image.cold.1 + 35 6 libcairo.2.dylib 0x10dedad50 _cairo_surface_release_source_image + 32 7 libcairo.2.dylib 0x10df05899 DataProviderReleaseCallback + 25 8 CoreGraphics 0x7ff80ce467f1 data_release_info + 31 9 CoreGraphics 0x7ff80cdff8bd data_provider_finalize + 54 10 CoreGraphics 0x7ff80cdc7a68 data_provider_retain_count + 74 11 CoreFoundation 0x7ff8077c6906 _CFRelease + 515 12 CoreGraphics 0x7ff80ce25e93 image_finalize + 103 13 CoreFoundation 0x7ff8077c681b _CFRelease + 280 14 CoreGraphics 0x7ff80ce6d411 CG::DisplayListResourceImage::~DisplayListResourceImage() + 23 15 CoreGraphics 0x7ff80ce6d3ea CG::DisplayListResourceImage::~DisplayListResourceImage() + 14 16 CoreGraphics 0x7ff80d41a407 std::1::shared_ptr::~shared_ptr[abi:v160002]() + 49
17 CoreGraphics 0x7ff80d412893 std::1::tree<std::1::shared_ptr, CG::CompareResourceImage, std::1::allocator<std::1::shared_ptr>>::destroy(std:: 1::tree_node<std::__1::shared_ptr, void>) + 47
18 CoreGraphics 0x7ff80d41287e std:: 1::tree<std::1::shared_ptr, CG::CompareResourceImage, std::1::allocator<std::1::shared_ptr>>::destroy(std::1::tree_node<std::1::shared_ptr, void>) + 26
19 CoreGraphics 0x7ff80d41287e std::1::tree<std::__1::shared_ptr, CG::CompareResourceImage, std:: 1::allocator<std::1::shared_ptr>>::destroy(std::1::tree_node<std:: 1::shared_ptr, void>) + 26
20 CoreGraphics 0x7ff80ce6d2d3 CG::DisplayList::~DisplayList() + 301
21 CoreFoundation 0x7ff8077c681b _CFRelease + 280
22 libobjc.A.dylib 0x7ff8072640d5 object_cxxDestructFromClass(objc_object, objc_class) + 83
23 libobjc.A.dylib 0x7ff80725d2f0 objc_destructInstance + 96
24 libobjc.A.dylib 0x7ff80725d289 _objc_rootDealloc + 62
25 AppKit 0x7ff80b4c8b6e -[NSViewBackingStoreImage dealloc] + 41
26 QuartzCore 0x7ff80fec40d5 CA::release_objects(X::List<void const>) + 21
27 QuartzCore 0x7ff80feb5258 CA::Transaction::commit() + 1548
28 AppKit 0x7ff80ad2b0bd 62+[CATransaction(NSCATransaction) NS_setFlushesWithDisplayLink]_blockinvoke + 285
29 AppKit 0x7ff80b66ce99 NSRunLoopObserverCreateWithHandler_block_invoke + 41
30 CoreFoundation 0x7ff8076fdfac CFRUNLOOP_IS_CALLING_OUT_TO_AN_OBSERVER_CALLBACK_FUNCTION + 23
31 CoreFoundation 0x7ff8076fded1 CFRunLoopDoObservers + 493
32 CoreFoundation 0x7ff8076fd453 CFRunLoopRun + 850
33 CoreFoundation 0x7ff8076fcae9 CFRunLoopRunSpecific + 557
34 HIToolbox 0x7ff812312819 RunCurrentEventLoopInMode + 292
35 HIToolbox 0x7ff812312456 ReceiveNextEventCommon + 201
36 HIToolbox 0x7ff812312371 _BlockUntilNextEventMatchingListInModeWithFilter + 66
37 AppKit 0x7ff80abce571 _DPSNextEvent + 880
38 AppKit 0x7ff80abcd2d3 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1304
39 libgdk-3.0.dylib 0x10f5abc4c poll_func + 172
40 libglib-2.0.0.dylib 0x10d82648d g_main_context_iterate + 445
41 libglib-2.0.0.dylib 0x10d826594 g_main_context_iteration + 100
42 libgio-2.0.0.dylib 0x10e4f823d g_application_run + 541