New runtime graphics error in Mac OSX Mojave with FLTK 1.4.x

87 views
Skip to first unread message

Maxie Schmidt

unread,
Nov 6, 2018, 5:06:35 PM11/6/18
to fltk.general
Hello again. 

I am running into more issues with another install of FLTK 1.4.x on Mojave. This error (compared to the one I am still having issues with from last week) is actually running on a colleague's Mojave box which is separate from the install I have running on my personal setup. I'm getting the following new runtime error when callbacks are issued for things like button presses which update the window and responses to drop down menu selection:

Assertion failed: (s->stack->next != NULL), function CGGStackRestore, file /BuildRoot/Library/Caches/com.apple.xbs/Sources/CoreGraphics/CoreGraphics-1245.8.4.8/CoreGraphics/Context/CGGStack.c, line 77.

Abort trap: 6


This link on wxWidgets is recent and is the only thing I've been able to find about this issue online. Any suggestions for how to fix this runtime error? (Besides just avoiding Mojave, or Mac OSX, as a developement platform all together, which is what I'm tempted to do as of recent) 

Thanks. Any suggestions for a fix are much appreciated.

Maxie

imm

unread,
Nov 6, 2018, 5:26:16 PM11/6/18
to general fltk
Have you tried linking your fltk build against an older OSX SDK? Say
10.13 or etc.

That should duck all the recent weirdness tat Apple have introduced. Possibly...

Maxie Schmidt

unread,
Nov 6, 2018, 6:03:32 PM11/6/18
to fltk.general
I'm definitely open to doing this if you could explain to me how to install an older SDK and how to link with it. I'm actually fairly new to Mac development and have just inherited a large pile of windowing code in C++ which now must work on Apple platforms. 

There's also this consideration, which is that the end users of the application I'm developing are not expected to be technically savvy, or even have sudo access to the box in question. Can you describe how to get this option working using brew, or just stock OSX tools?

Maxie Schmidt

unread,
Nov 6, 2018, 10:04:08 PM11/6/18
to fltk.general
Thanks Ian. I believe that this process will work **if you have an Apple developer account AND if you have sudo access on the build machine in question**. Note that this will take some time. 
  1. Download Command Line Tools (macOS 10.13) for Xcode 9.4 and Xcode 9.4 to your home directory
  2. Run the following sequence of commands (again, can take some time depending): 
    $ hdiutil attach Command_Line_Tools_macOS_10.13_for_Xcode_9.4.dmg
    $ cp
    /Volumes/Command\ Line\ Developer\ Tools/*.pkg ./CmdLineTools-MacOSHighSierra-version10.13.pkg
    $ installer -store -verboseR-pkg "/Users/YourUsername/
    CmdLineTools-MacOSHighSierra-version10.13.pkg" -target /
    $ xip-x XCode-9.4.1.xip
    $ sudo mkdir -p /Library/Developer/XCode
    $ sudo cp -r Xcode.app/Contents/Developer /Library/Developer/XCode
    $ sudo xcode-select -s /Library/Developer/XCode
    $
    sudo xcodebuild -license
    $ xcrun --sdk macosx --show-sdk-version
    # > Should now be something like: 10.13

Now build and link your FLTK 1.4.x library and app with dependencies as you would expect... I used the following recipe to build and install FLTK 1.4.x on Mojave:
$ export CC="clang -g -arch $(uname -m) -DBUILD_SHARED_LIBS -D__APPLE__"
$ export CXX="clang++ -g -arch $(uname -m) -DBUILD_SHARED_LIBS -D__APPLE__"
$ mkdir
-
/usr/local/opt/fltkwithcairo

$ make clean && ./configure --enable-cairo --enable-threads --prefix=/usr/local/opt/fltkwithcairo
$ make && make install


It's a shame that this is what it's come to with developing with recent Apple platforms. It really seems like they're intentionally trying to break open source software that has worked on their systems for ages!

At any rate, is it possible that there's another fix that can be linked directly against the 10.14* SDK libraries and still fix the problem, i.e., another line or two that could be added to the FLTK 1.4.x source to prevent the original error from happening?

Maxie

Manolo

unread,
Nov 7, 2018, 4:38:41 AM11/7/18
to fltk.general
This means there's one more call to CGContextRestoreGState
than to CGContextSaveGState in the code. That can be in the
code of your app, or in the code of a library called by your app.

FLTK is known not to do this.

From another viewpoint: does that mean that you could build
the patched FLTK 1.4 library on that other machine.?
Can you run the test/cairo_test demo program on that machine,
and hide/show the app without the graphics turning upside-down?
The effect of the patch is to repair that error.

Maxie Schmidt

unread,
Nov 7, 2018, 9:55:20 AM11/7/18
to fltkg...@googlegroups.com
It might take me a couple of days to run the patched code. For the extra context reference, this error is only getting triggered when a callback (presumably to redraw the fl_cairo_window) from s widget is getting called. Is it possible that there is a bug in the way that Cairo contexts are getting handled? The only other library headers I have included besides cstdlib are to Cairo. What should I look for to track down this type of bug?

--
You received this message because you are subscribed to the Google Groups "fltk.general" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fltkgeneral...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Manolo

unread,
Nov 7, 2018, 9:59:48 AM11/7/18
to fltk.general
Let's first see if the patch does not solve this.
Reply all
Reply to author
Forward
0 new messages