Hi Sergio, John
I can reproduce, and yes for me the problem comes clearly from a mix up of the usage of the libX11.dylib taken from /opt/local/lib (then coming from a MacPorts installation) and the usage of the libGL.dylib taken from /opt/X11 (then coming from the XQuartz installation). (And for which there is a symlink from /usr/X11R6; are really nasty point) (and which is installed under /opt, which is confusing relative to MacPorts that installs under /opt/local).
If in the build of your example, you do a “export VERBOSE=1” (or “setenv VERBOSE 1”, if under a csh), and then do “make” again (by rooming the RE03 binary), you will probably see that in the (long) link command, you too mix both.
If I use the Geant4 dylib, in fact I have a crash with something as :
assertion failed: (pthreadret == 0), function _xcb_in_wake_up_next_reader, file xcb_in.c, line 926
and if I use the Geant4 .a static libs, I have the same problem that you describe. I think that “it passed” at the time of Morave because the two lib sets where not so much different, but now there is clearly a big gap, at least concerning the dates and sizes from the libs coming with MacPorts and the ones of XQuartz.
THEN, what is bad, is that for me the cmake on the build of Geant4 clearly says :
– Found X11: /opt/local/include
– Looking for XOpenDisplay in /opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib
– Looking for XOpenDisplay in /opt/local/lib/libX11.dylib;/opt/local/lib/libXext.dylib - found
and for OpenGL :
– Found XQuartzGL: /opt/X11/include
then the cmake mixed both libs. What I did for the moment is just tweak the :
cmake/Modules/FindXQuartzGL.cmake
to use the GL found under /opt/local/include and /opt/local/lib. It is easy to do, just replace the PATHS
in this file to use only these. And then coffee + rebuild…
Note that you may not have the libGL in your MacPorts area, if not, you can have have them with:
sudo port install mesa (or glxinfo, or better libGLU to have also libGLU)
Then when building your example, cross check the link command and run… It should pass… (with G4 dylibs or .a). (Then you should see in the link command : /opt/local/lib/libX11.dylib and /opt/local/lib/libGL.dylib).
In my things, I use MacPorts for all my X11 things, and I changed them to enforce the usage of libGL coming from that. I think that we must definitely forget the libs of XQuartz when building and run “X11 clients”. One critical point is that for example Motif (I still use it, and is still usable with Geant4), does not come with XQuartz, but can be installed with MacPorts in a consistent way with the rest. (I cross checked, and all my Motif apps doing GL is ok on Catalina if being “all MacPorts”).
If someone install things with Brew, it should be the same, someone must use all X11, GL, (Motif) coming with it. (I don’t like Brew, it touches things under /usr, which does not do MacPorts. With MacPorts all is under /opt/local (I think) (I hope)).
Then try by “arranging” to use “consistent” libX11 and libGL…
Well, if you do not want to use anything from MacPorts or Brew, you will have to find a way to enforce the usage of the XQuartz X11 in the G4 cmake, but I don’t know how to do that.
And (for the vis group), it is clearly needed to revisit the G4 cmake logic to be sure to be consistent with X11 and GL (and Motif) (both should be taken from the same source; or XQuartz, or MacPorts, or Brew).
Cheers. Let us know… Guy
(And next year we are going to have “Big Sur” with another architecture. More fun is going to come… 
)
