weixin_40008870
2020-12-31 03:03 阅读 1

Fixed compilation failing on macOS

Tested and confirmed to work correctly on macOS Mojave (10.14.6).

Funnily enough, only some minor changes in configure bash script were needed in order to compile this on macOS 😄

该提问来源于开源项目:wjaguar/mtPaint

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 复制链接分享

13条回答 默认 最新

  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    mtPaint 3.40 having sat in MacPorts for a decade, a major incompatibility with a MacOS would have been a surprise indeed. ;) As to the actual changes you made, I assure you all those compiler flags you decided to disable, are there for a reason. Does the C compiler on Mojave actually fail to accept them, or what? If it does fail, please tell me what compiler version it is and what actual error(s) do happen.

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    Now that's something… Maybe MacPorts has custom patches for mtPaint? I don't know, since I only use brew.

    Anyways, there is absolutely no way mtPaint could possibly ever compile on a Mac out of the box, just because it wants to link to -lX11 😉 And there is also that --as-needed flag that is completely unsupported too.

    I've also disabled -s: on macOS, because it's deprecated and generates unnecessary warnings.

    My toolchain is as intended to be on Mojave, nothing unexpected:

    clang:

    
    Apple LLVM version 10.0.1 (clang-1001.0.46.4)
    Target: x86_64-apple-darwin18.7.0
    Thread model: posix
    

    ld:

    
    @(#)PROGRAM:ld  PROJECT:ld64-450.3
    BUILD 18:45:16 Apr  4 2019
    configured to support archs: armv6 armv7 armv7s arm64 arm64e arm64_32 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em
    LTO support using: LLVM version 10.0.1, (clang-1001.0.46.4) (static support for 22, runtime is 22)
    TAPI support using: Apple TAPI version 10.0.1 (tapi-1001.0.4.1)
    

    There are still some minor issues, such as gtk2 version being painfully slow, color picker not working (neither on gtk2 nor on gtk3) at all and crashing, and also brush outline guide traces:

    brush outline guide traces

    But all those are completely separate issues, and I'm not even sure if the latter one is even related to macOS; maybe those are just bugs in Gtk itself after all 🙂

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    And as to brush outline, maybe Quartz backend does not properly simulate window-leave events? Does the thing disappear again when the cursor is once more moving over the image (in some distant place of it), or does it sit there still?

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    When the toolchain is nothing unexpected to you, thing is, LLVM is totally unsupported by me

    There is no official, or even reliable way to get GCC working on macOS, that's what I meant by saying that there is nothing unusual from my side.

    I think X11-for-MacOS still remains a possibility for someone's setup, does it not?

    It's long gone and nobody pines for it.

    As to "--as-needed", lightweight cross-builds will just plain not work without it, so I'll have to find a compatible MacOS-specific option to replace it by in that mode, unless that is not the default behaviour there.

    AFAIK that's exactly the case

    As to deprecated "-s", a compatible option would still be the way to go if at all possible, as the unnecessary symbol tables add quite a bit of bulk to a binary, and running 'strip' separately is a more intrusive change.

    Correct me if I'm wrong, but isn't strip just ran by default here?

    I get a binary slightly smaller than 1M when compile with the following configuration:

    
    configure gtk3 release --cpu=haswell GIF jp2v2 tiff webp jpeg intl man freetype lcms2 gtkcolsel gtkfilesel imagick
    

    Maybe let's just leave that "-s" there so that people with ancient toolchains can benefit from it, huh?

    As to "color picker" crashing, which part do you mean? The color editor window (such as in "Palette -> Edit colour A&B"), the color chooser ("Edit -> Choose colour"), or the pipette in color editor? If the first or the third, then what happens if you use the "gtkcolsel" configure option?

    Ah, my bad here, I mean the color picker that's supposed to be invoked from the dropper/pipette button in the color editor. It refuses to work both when compiled with the mtpaint native dialog and with gtkcolsel, but invoking the former also causes the user interface to cease responding to mouse input and spit whole lots of errors on terminal; a small snippet shown below:

    
    (mtpaint:15384): GLib-GObject-CRITICAL **: [REDACTED]:53.759: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:53.759: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:53.759: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:53.759: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): GLib-GObject-CRITICAL **: [REDACTED]:53.759: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:53.759: gtk_widget_is_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): GLib-GObject-CRITICAL **: [REDACTED]:53.759: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:55.006: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:55.008: gtk_widget_get_toplevel: assertion 'GTK_IS_WIDGET (widget)' failed
    (mtpaint:15384): Gtk-CRITICAL **: [REDACTED]:55.008: gtk_widget_is_sensitive: assertion 'GTK_IS_WIDGET (widget)' failed
    

    And as to brush outline, maybe Quartz backend does not properly simulate window-leave events? Does the thing disappear again when the cursor is once more moving over the image (in some distant place of it), or does it sit there still?

    That trace persists no matter how much I scroll the canvas or move my mouse; it only vanished when zooming in or out.

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    Steps to trigger outline traces (they might be barely visible on this video depending on quality of your display):

    recording1

    Steps to reproduce the dropper bug:

    recording2

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    GIMP 2.10 has a specialcased implementation of pipette for Quartz backend

    Do you mean this?: https://gitlab.gnome.org/GNOME/gimp/-/blob/master/libgimpwidgets/gimppickbutton-quartz.c

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    Steps to trigger outline traces (they might be barely visible on this video depending on quality of your display):

    Thanks, I reproduced it here. Sadly, the problem is threefold; your display being HiDPI, GTK3 devs being idiots, and mtPaint not yet having builtin HiDPI support to counteract the second part. In short, plain old pixel doubling is apparently not fancy enough for some people, so GTK_SCALE=2 applies some filter that causes every pixel to bleed into its neighbors. mtPaint's redraw calculations being (naturally) pixel-precise, the bleed does not get cleared up. The worse thing actually is canvas' pixels bleeding into one another; this damage rather defeats the very point of mtPaint as a pixel editor.

    I did not expect things to be THAT bad and hoped to defer HiDPI stuff till after the 3.50 release, to version 3.51.

    Steps to reproduce the dropper bug:

    Thanks, this will make it easier to find out what, exactly, went wrong in the implementation.

    Do you mean this?: https://gitlab.gnome.org/GNOME/gimp/-/blob/master/libgimpwidgets/gimppickbutton-quartz.c

    Yes, but maybe something could be made without resorting to ObjectiveC. BTW, does the screenshot function (File->New->Grab screenshot) work on MacOS?

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    Regarding HiDPI, that's true. I've just tried to run mtPaint on my external display (1:1) and the bleeding is not an issue there. Even better, mtPaint becomes much faster and more responsive when its window is moved to that display.

    Do you mean this?: https://gitlab.gnome.org/GNOME/gimp/-/blob/master/libgimpwidgets/gimppickbutton-quartz.c

    Yes, but maybe something could be made without resorting to ObjectiveC.

    Yes, you could use this particular Carbon C API, alas, it'd been deprecated since Catalina.

    does the screenshot function (File->New->Grab screenshot) work on MacOS?

    Unfortunately it does not, mtPaint minimizes itself and then restores after a while with nothing more than just an empty picture 😞

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    At the moment, I have a fix for the color bleeding, will include it in 3.49.30 along with whatever other MacOS related fixes I can implement without ObjectiveC (which I have nowhere to test). An option to have canvas at HiDPI display's native resolution needs more churn than is healthy right before a release, so will likely have to wait till 3.51.

    As to slowness, may be the Quartz backend; on Linux/X11 with Nvidia driver, no noticeable slowdown from GDK_SCALE=2 compared to default state of GTK3, and the blits where the canvas may get scaled (buffer to backing surface) are on the order of a few microseconds in either case.

    you could use Carbon C API, alas, it'd been deprecated since Catalina.

    The "Not available to 64-bit applications." looks like a showstopper. :(

    mtPaint minimizes itself and then restores after a while with nothing more than just an empty picture

    Could you compile and run tests/testpixbuf-save.c from GTK3 and tell me whether it does capture a piece of screen, or ends up with nothing too? https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/tests/testpixbuf-save.c

    BTW, it appears clipboard import/export will too require some changes to make it work on MacOS, as some parts of API are dummy stubs in the Quartz backend, also the native format is TIFF which is optional in mtPaint builds.

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    whatever other MacOS related fixes I can implement without ObjectiveC (which I have nowhere to test).

    If you had time, you could try Darling. You can PM me for more information on that if you want to.

    Could you compile and run tests/testpixbuf-save.c from GTK3 and tell me whether it does capture a piece of screen, or ends up with nothing too?

    
    $ gcc -o testpixbuf-save testpixbuf-save.c $(pkg-config --libs --cflags {gtk+-3.0,glib-2.0})
    $ ./testpixbuf-save
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.470: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.470: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    X:200 Y:200
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.495: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.519: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.519: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.519: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.520: drawing failure for widget 'GtkDrawingArea': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.520: drawing failure for widget 'GtkBox': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.520: drawing failure for widget 'GtkWindow': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.539: gdk_pixbuf_get_n_channels: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.539: gdk_pixbuf_get_width: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): GdkPixbuf-CRITICAL **: [REDACTED]:51.539: gdk_pixbuf_get_height: assertion 'GDK_IS_PIXBUF (pixbuf)' failed
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.539: drawing failure for widget 'GtkDrawingArea': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.539: drawing failure for widget 'GtkBox': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    
    (testpixbuf-save:48994): Gtk-WARNING **: [REDACTED]:51.539: drawing failure for widget 'GtkWindow': invalid value (typically too big) for the size of the input (surface, pattern, etc.)
    

    Nothing more than a blank window shows up.

    BTW, it appears clipboard import/export will too require some changes to make it work on MacOS, as some parts of API are dummy stubs in the Quartz backend, also the native format is TIFF which is optional in mtPaint builds.

    I love Gtk…

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    Could you please do another test? With this program: https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/tests/testgtk.c Specifically, the dialog that "test selection" button (need to scroll down for it) displays; it would be very useful for me to know what, exactly, "Get Targets" there would display after some native MacOS app put an image onto clipboard (preferably an image with transparency); same thing when the image is originally a PNG file; and if possible, same when it is a TIFF, and same when it is a BMP.

    If you had time, you could try Darling.

    The "we finally have basic experimental support for running simple graphical applications. It requires some special setup for now though, so do not expect it to work out of the box just yet" does not look that promising for testing and debugging GUI stuff. :(

    点赞 评论 复制链接分享
  • weixin_40008870 weixin_40008870 2020-12-31 03:03

    Here are the results of running that test:

    testgtk

    As a bonus, a portrait of the Gtk lead dev can be seen on the right part of my screen 🙃

    点赞 评论 复制链接分享
  • weixin_39658716 weixin_39658716 2020-12-31 03:03

    I hope with version 3.49.30 I got some issues fixed; namely configuring, canvas, and clipboard import/export.

    Clipboard still needs testing; I added debug output to the console when mtPaint attempts to import clipboard on GTK+3/Quartz, to do what "testgtk" so utterly failed at. Whether the import ends up working or not, the output from the testcases that I described on October 8th will be much appreciated.

    As to pipette in color editor, I ended up disabling the button for now, having nowhere to debug Mac-specific GUI stuff and having also learned that anyway since Catalina, "screen recording" need be allowed for the program in privacy settings for anything like that to work at all (so there goes the screenshot capability too).

    点赞 评论 复制链接分享

相关推荐