[R-SIG-Mac] rgl configure error: "missing required library GL"
pdalgd at gmail.com
Tue Jul 24 11:08:06 CEST 2012
On Jul 23, 2012, at 20:49 , Duncan Murdoch wrote:
> On 23/07/2012 2:31 PM, peter dalgaard wrote:
>> On Jul 23, 2012, at 19:13 , Duncan Murdoch wrote:
>> > On 23/07/2012 12:55 PM, Grimes Mark wrote:
>> >> I wonder if this is related. Package 'rgl' failed to load in an error
>> >> similar to one I've had previously. It was working for a while and
>> >> now it is not working again. R output attached
>> > I think that's a different problem. The original one in this thread (which should now be fixed) caused R
> That should have been "rgl to fail to build", of course...
>> to fail to build. This one causes it to fail to run on some newer MacOSX systems. (Newer than what I have, anyway.) This is probably caused by Apple changing their API; I don't know a fix, but a workaround is to delete the aglrgl.so library mentioned in the error message. rgl will fall back to the X11 library, which still works.
>> I think they are somewhat related. I managed to build an rgl package that loaded neatly into R.app and ran without requiring X (somewhat smoother than the X version, I might add). However, some attempts along the way gave symptoms with missing symbols. The generic issue seems to be that when you build the binary package, there may be warnings about missing support libraries but aglrgl.so is still created. The final step of the package build is to test whether the package can be loaded, but since the build is from the command line, the X11 route is taken, and that may well work in spite of a broken aglrgl.so.
>> In my note from July 17, I mentioned that I had trouble on 32 bit, and that was exactly because some of my libs were 64 bit only. Those were MacPort builds, but I don't think it actually matters. Simon does things slightly differently, but I would conjecture that there might be a lib that is found in 32 bit only on the build machine.
> That's encouraging. If anyone spots a change I can make to the rgl sources to help, please let me know.
Digging a little deeper, the missing __ZN.*hasEventLoopEv symbol is supposed to be defined in osxgui.o, so when it is undefined in the installed aglrgl.so on one architecture, it is likely that R CMD SHLIB got confused by a pre-existing osxgui.o of another architecture. I.e., this symptom is probably caused exactly by the packaging issue that Davor caught, and might well have disappeared all by itself by now, as the binary package has been rebuilt from a cleaned tarball.
The issue with support libs is still there, the symptoms are similar, but the missing symbol will be different. I've seen that with freetype. The root cause of it all is that aglrgl.so is never test-loaded (because command-line R has .Platform$GUI=="X11"), but I'm at a loss as to how you can stage that.
>> >> __ZN3gui13OSXGUIFactory12hasEventLoopEv
>> >> Referenced from: /Library/Frameworks/R.framework/Versions/2.15/
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
More information about the R-SIG-Mac