glCreateShader fails on MacOS M1 about solvespace

[dgramop]

Just checked out the 70bde63 commit, and I'm unable to run this either, after compiling. The "installed" version seems to run just fine. Here's how I'm invoking cmake:

cmake -DCMAKE_BUILD_TYPE=Debug -DENABLE_OPENMP=ON ..

[dgramop]

What's driving me crazy is that this did work earlier today, all until I re-ran cmake...

Edit: debug output has confusing results. glGetError() returns 0 (enum value corresponding to "no error") and the result from glCreateShader is 0, which represents there was an error

Process 9959 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = step over
    frame #0: 0x000000010002aa70 SolveSpace`SolveSpace::CompileShader(res="shaders/edge.vert", type=35633) at gl3shader.cpp:106:5
   103
   104      GLuint shader = glCreateShader(type);
   105      int err = glGetError();
-> 106      glGetError();
   107      ssassert(shader != 0, "glCreateShader failed");
   108
   109      const GLint   glSize[]   = { (int)src.length() };
Target 0: (SolveSpace) stopped.
(lldb) p err
(int) 0
(lldb) p shader
(GLuint) 0
(lldb) n

[ruevs]

I've only tried to build the macOS version with a fairly old macOS and XCode.

• Some updates?
• Do the shaders get linked?
• Apple have been "talking" about deprecating OpenGL for a while... but the release works for you...
• Try if the artefact from the latest CI build on master works. https://github.com/solvespace/solvespace/actions/runs/7400855007

Perhaps @vespakoen can help you - he works on a Mac.

[dgramop]

By some updates, I mean a minor version of MacOS and some fresh homebrew packages. When I build the latest release myself I get the same problem. Doubt it’ll replicate with the CI prebuilt since I’m able to run the installed version, but I’ll check and report back. I’m not actually sure how shaders are linked, how should I go about testing for this? Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: ruevs ***@***.***> Sent: Sunday, March 24, 2024 1:57:21 AM To: solvespace/solvespace ***@***.***> Cc: Dhruv Gramopadhye ***@***.***>; Author ***@***.***> Subject: Re: [solvespace/solvespace] glCreateShader fails on MacOS M1 (Issue #1454) I've only tried to build<https://github.com/solvespace/solvespace?tab=readme-ov-file#building-on-macos> the macOS version with a fairly old macOS and XCode. * Some updates? * Do the shaders<https://github.com/solvespace/solvespace/tree/master/res/shaders> get linked? * Apple have been "talking" about deprecating OpenGL for a while... but the release works for you... * Try if the artefact from the latest CI build on master works. https://github.com/solvespace/solvespace/actions/runs/7400855007 Perhaps @vespakoen<https://github.com/vespakoen> can help you - he works on a Mac. — Reply to this email directly, view it on GitHub<#1454 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ACTRHOGEXVJWBWTF37P3FJTYZ2IPDAVCNFSM6AAAAABFFGWDGOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMJWG42DAMZTGE>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[dgramop]

Just tested with the latest macOS artifact and it works. Definitely something wrong with how I'm building this.

Also it seems that glCreateShader is just a constructor and doesn't actually take a particular shader file yet...

CMAKE: -- Found OpenGL: /opt/homebrew/lib/libGL.dylib
and
/opt/homebrew/lib/libGL.dylib -> ../Cellar/mesa/24.0.3/lib/libGL.dylib

Edit: tried uninstalling mesa and re-running cmake to get solvespace to link to the framwork, no change in behavior

Edit: Went ahead and checked glGetError() after the call to makeCurrentContext. I get back a value of 0. So it seems that there was no error when the context was originally created either.

[dgramop]

Wrote a dummy program and linked to the OpenGL framework:

clang -g -framework OpenGL test.c

Then ran otool -L to see what dynamic links it made:

./a.out:
	/System/Library/Frameworks/OpenGL.framework/Versions/A/OpenGL (compatibility version 1.0.0, current version 1.0.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1345.100.2

Looks like it's using openGL 1.0.0 from the system in the dummy program... which of course SIGSEGV's if I make any calls to functions in the gl3 headers, which happen to be provided in that same Frameworks folder (even though apparently version 3 is not available?)

Maybe somehow I lost openGL version 3... also interesting to see that came picks mesa libGL form home-brew when I had that installed. Maybe there's a difference between the version of libGL that gets headers compiled in and the one that gets dynamically loaded on my system....

[dgramop]

[ 82%] Copying resource locales/zh_CN.po
[ 83%] Copying resource shaders/edge.frag
[ 83%] Copying resource shaders/edge.vert
[ 83%] Copying resource shaders/imesh.frag
[ 83%] Copying resource shaders/imesh.vert
[ 83%] Copying resource shaders/imesh_point.frag
[ 84%] Copying resource shaders/imesh_point.vert
[ 84%] Copying resource shaders/imesh_tex.frag
[ 84%] Copying resource shaders/imesh_tex.vert
[ 84%] Copying resource shaders/imesh_texa.frag
[ 84%] Copying resource shaders/mesh.frag
[ 86%] Copying resource shaders/mesh.vert
[ 86%] Copying resource shaders/mesh_fill.frag
[ 86%] Copying resource shaders/mesh_fill.vert
[ 86%] Copying resource shaders/outline.vert
[ 86%] Copying resource threejs/SolveSpaceControls.js
[ 86%] Copying resource threejs/hammer-2.0.8.js.gz
[ 87%] Copying resource threejs/three-r111.min.js.gz
[ 87%] Built target resources

^ in case this is what you mean by shaders being linked

Also maybe we should bring CI from macOS 12 to macOS 14

Mesa bumped a major version around the time I went inactive... Will investigate this

[dgramop]

Ladies and Gentlemen, We Got Him

This bug has been driving me nuts every time I feel like working on solvespace.

Digging around with otool, I took the known good & working builds from CI and did a diff between the dylibs for working vs good.

This led me to uninstall libGL provided by Mesa from homebrew. After I did that, my build somehow tried linking to /opt/local/lib/libGL.1.dylib (which was not linked to by the known-good one). As a quick hack I edited build/src/CMakeFiles/solvespace.dir/link.txt (generated by cmake) and removed "/opt/local/lib/libGL.1.dylib". I ran make, opened it up, and my built Solvespace loaded up without crashing!

I owe this thread and future readers a more stable fix, so I'll do some further diagnosing, document the fix, and close the issue.

TL;DR: If this happens to you, consider comparing your build's dylib paths with the known good one. Make sure to not have Mesa installed (even though it may be used by solvespace on other platforms).

[dgramop]

When running cmake .. -DCMAKE_BUILD_TYPE=Debug -DENABLE_OPENMP=ON
The culprit is:

....
-- Found OpenGL: /opt/local/lib/libGL.dylib
....

find_package(OpenGL REQUIRED) in CMakeLists.txt is what locates this file. That file seems to just exist on my mac (and as far I know shipped with my mac). It doesn't symlink anywhere to homebrew and I didn't manually build & install any openGL. I think my install of openCV is what created this mess.

So TL;DR: All we need to do to link OpenGL is give Clang the -framework OpenGL file, and nothing else. The additional stuff that find_package gives back can result in weird conflicting/broken links to libGL. Maybe there's something to be fixed within Cmake's FindOpenGL module itself. Till then we should just use -framework OpenGL

[dgramop]

I got another apparent dynamic linker error when building on my mac (but not on prebuilt resources) for error dialogs. Will investigate this eventually

(edit: the "apparent" dl error was just that. Seems that this problem is localized to GL)

[vespakoen]

Try compiling locally using the github scripts, it might help?

.github/scripts/install-macos.sh ci
.github/scripts/build-macos.sh release arm64

CI is up and running again for macOS so new pre-compiled binaries should be available soon...