MacOSX: allow build with homebrew and its emulated MesaGL

[dk]

This change comes from Prima::OpenGL that is built with Prima that uses lots of homebrew libraries, and is actually advised to be built on homebrew. The problem comes with the libraries that are implicitly dependant on the native /opt/X11 libraries, and any program that is compiled with both set of Xlibs (and by extention, GL libs), dumps core.

A possibile solution to this is to let OpenGL::Modern to use homebrew libraries, but that comes with a price, native mac gl will not be used, but the slow emulated MesaGL will be used instead.

[coveralls]

Pull Request Test Coverage Report for Build 20510719765

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 20.253%

---

Totals
Change from base Build 15380809697:	0.0%
Covered Lines:	16
Relevant Lines:	79

---

💛 - Coveralls

[mohawk2]

XQuartz is extremely slow to start, and because of the emulation, there is no hardware acceleration. What benefit does using the emulated Mesa bring for MacOS?

[dk]

The benefit is binary compatibility with homebrew. This should never be a default build (note the explicit "env WITH_HOMEBREW=1"), but I think that if one insists, for whatever reasons, one should have a possibility to build everything with homebrew only, and not have coredumps because of different versions of shared libraries linked together.

( btw I don't agree that 1-2 seconds for first instance of XQuartz to start is "extremely slow" )

[mohawk2]

On my Intel Mac, XQuartz takes 15s or more to start. FreeGLUT (from Homebrew, pulling in XQuartz and Mesa) as used in POGL doesn't get segfaults on my system when the system OpenGL library is also linked in. The change which I saw you make in Prima::OpenGL to disable using the system OpenGL on MacOS has now made it not compile on my machine. That won't be happening for this library.

[dk]

Hmm that's interesting... so the latest Prima::OpenGL doesn't compile on your setup with homebrew? Could you possible share the setup so I can try to reproduce?
Because if there is a way to use homebrew that would indeed much better outcome than using Mesa.

Of course you don't see coredumps on OpenGL::Modern, because there is no clash there. On my setup I observed the clash when Prima links with X11 libs from homebrew, and in POGL these in turn pull GLX and after that, GL also from homebrew (and thus, Mesa). Only when OpenGL comes into the picture, these two GL libraries explode.

But this aside, you don't want homebrew's Mesa in principle, or ...?

[mohawk2]

To be clear, Mesa is on the device via Homebrew. I repeat that the latest OpenGL on master links to FreeGLUT from Homebrew, and the Perl process also loads OGLM for many of the functions.

It would really help if you'd make a CI addition for this that you can show works with GL as you have it locally. It would help Prima-OpenGL quite a lot if you had CI on that, which I'm not currently seeing.

[mohawk2]

Also, I highly recommend that since you now dep on OGLM, you should use the OpenGL::Modern::Config info I made especially for this purpose. If you're looking to avoid X11 stuff on MacOS, GLFW provides good code to copy for window-opening and widget stuff.

[dk]

I'm not seeking to get rid of X11, quite the other way as Prima needs X11. But I'll try to look into CI if there is mac-based one provided by github or whoever else... I'll be back in March, will look into that.

[mohawk2]

Great. By the way, Prima itself is breaking on my Mac device, which I'll take a look at in a while.

I did say "if" you want to get rid of X11 for MacOS: I believe that relying on XQuartz in 2026 doesn't make for a good user experience, and it would be worth making Prima do "native" MacOS.

[dk]

Oh well, native Cocoa for Prima, that's a really painful one ... I don't think will ever have energy for that :(

[mohawk2]

Pity. There is more prior art to steal from, Qt, which implements a GUI: https://github.com/qt/qtbase

By the way, glew.c is directly excerpted from GLEW's glewinfo.c, so I won't accept patches in the middle of it since that would turn into a nightmare next time GLEW gets updated. The way forward there would be to make a PR to GLEW.

Finally, I really need more information on the segfault you say you're seeing. I can't reproduce it myself; if I could, there might be a better way. Also, I had a weird situation a while ago when P:G:TriD was still in main PDL, where the GNU readline would lose its history if TriD stuff was used. It turned out this was because OpenGL loaded LLVM, which loaded libedit (which is either a fork of, or at least looked at the source of, readline), which had some similar symbols. If OpenGL was loaded before the particular readline function that did history was called, the libedit symbol "won"; if the readline function was called first, it won. In other words, it might be possible to avoid the whole segfault by being canny about symbol management.

[dk]

Well the segfault and the coredump, they don't bear much of useful info, but the ldd (or rather otool -L) output does. The thing goes like this: Prima uses libX11 and Xft and all other X-related libs, and creates a config how to link with Prima.so if anyone desires - so far so good. OpenGL uses native Mac frameworks and libGL that understands it, but okay so far so good as well. Now POGL tries to link with libGLX using link flags from both Prima and OpenGL, but assuming there is no Mesa and no homebrew's libGLX, it pulls libGLX from the XQuartz distro, and in turn other X-related libs, fontconfig etc.. that's where problem begins. I observed that when f.ex. Prima code wants to use libXft which is linked with fontconfig, the linker brings in libfontconfig from the XQuartz distro, not from homebrew, and of course this explodes.

Now I am rereading this and it looks messy, but if you manage to build Prima and POGL and see the otool -L output you'll see what I mean. Btw what kind of a problem you observe with Prima build? You're welcome to submit a bug report...

[dk]

Btw how do you build OpenGL::Modern with homebrew/freeglut on mac? I'm looking into its Makefile.PL and it is very explicit about if system is darwin, use -framework OpenGL.

[mohawk2]

Btw how do you build OpenGL::Modern with homebrew/freeglut on mac? I'm looking into its Makefile.PL and it is very explicit about if system is darwin, use -framework OpenGL.

Perl OpenGL (for this context, I'll call that OGL.pm since you're saying POGL as Prima::OpenGL, whereas generally people say POGL and mean "Perl OpenGL" i.e. OGL.pm) on MacOS uses FreeGLUT if available, and Apple GLUT if FreeGLUT isn't available, or if instructed on the command-line. That's at the C linking stage. The master version (not yet released) now has deleted a lot of the bespoke XS and instead Perl-dynaloads OGLM for many of its functions. That means the Perl executable using the latest OGL.pm has both FreeGLUT (which I have as from Homebrew, which pulls in Mesa, and I'd assume the Homebrew OpenGL stuff too) and the Apple-supplied OpenGL in the same process. This works fine. If you want to see exactly how to reproduce this, look in the GitHub CI config for OGLM and OGL.pm.

From your note above, I would expect that explicitly getting the fontconfig stuff from Homebrew too would obviate the problem you're having. The fact that you don't have any CI at all for Prima:OGL, including for MacOS, doesn't help. You ought to fix that.

[dk]

I think I see what you mean. I've checked out the latest OGM and there is already a reservation for GLX on Apple, - that #define GLEW_APPLE_GLX seems like exactly what I was missing and that what I was trying to implement in the C code.

So I decided to test it: If I add manually -DGLEW_APPLE_GLX -I/opt/homebrew/include -L/opt/homebrew/lib -lglut -lglew that compiles and even rudimentarily works, except that the GL functions exported by mac's native framework don't recognize the context created by homebrew's implementation of GLX. ( If I complile with -I/opt/X11 instead then it does, but that's another story).

So let's for a time being put aside the native Apple's Metal which would be very nice, but just for this scope let's focus on the pure GLX setup... are you open to the idea to add a switch to Makefile.PL that would support GLEW_APPLE_GLX? It seems to be compiling alright whether it's homebrew or XQuartz.

[dk]

F.ex.something like this:

  if ( $ENV{USE_XQUARTZ} ) {
     $define .= " -DGLEW_APPLE_GLX -I/opt/X11/include";
     $libs = '-L/opt/X11/lib -lglut';
  }

-- that would work for me.

[mohawk2]

If you generalised that to env vars of OGLM_ADD_DEFINE and OGLM_ADD_LIBS which would get appended if defined, I'd accept that. But only if you add a CI case (presumably on MacOS) that actually exercises it, I'm afraid that's non-negotiable.

[dk]

I'll see if these env vars can be set to have the desired effect, sure. Btw about CI, would you recommend a decent CI setup for mac, preferrably for github actions?

[mohawk2]

I recommend highly the CI already on this repo. To be clear, I did say "add" a case on the CI on this repo, not make things wholly from scratch. I know how much agony went into making this one, so I'm only asking you to add to it, not make a whole new one.

Assuming you're asking in order to make CI on a different repo, then depending on what you are after, you may also benefit from looking at OGL.pm's CI setup, which is quite similar. If you don't want to dep on the actions @zmughal made, then you could copy-paste them, but if it's for your Prima ecosystem, you might benefit from making a devops repo and putting stuff there.

[nrdvana]

I'm not sure if it's equally useful for graphics/opengl, but for regular testing on Windows and Mac I'm pretty happy with https://github.com/shogo82148/actions-setup-perl as seen at https://github.com/nrdvana/perl-Crypt-SecretBuffer/blob/main/.github/workflows/ci.yml

[mohawk2]

That action is used by the whole PDL and POGL-o-sphere! Ironic given you mentioned it, but it's just started failing on MacOS and Linux, hopefully that will get sorted soon. Others have reported it: shogo82148/actions-setup-perl#2481

[dk]

I couldn't keep this PR to sync my fork, so I'll reopen it under a new number