Skip to content

rgl revisions to allow dual install

11 messages · stefano iacus, Duncan Murdoch, Simon Urbanek

#
I've just committed some changes to rgl to allow it to install two 
versions of its shared library on Mac OSX, one
for AGL and one for X11.  The build process ended up kind of messy, and 
I'm not sure it will work on ppc or other different Mac platforms.

This hasn't been sent to CRAN yet, but I've put a temporary build on my 
own web page at

http://www.stats.uwo.ca/faculty/murdoch/temp/rgl_0.69.535.tar.gz

Could someone else try installing this, and confirm it works 
transparently both in the GUI and from the console?

Thanks to Simon for inspiring this and providing some advice (though I 
couldn't get his cleaner solution to work; not sure why not).

Duncan Murdoch
#
It builds fine on PCC and apparently the two libs are in the  
installed directory.
The only problem is that both on X11 term and on R.app always the  
X11 .dll is taken, so no AGL for me any more.
I don't see any conditionals on .Platform$GUI in the loading of the  
library though.
stefano
On 11/dic/06, at 10:27, Duncan Murdoch wrote:

            
#
and, for the standard  shell (i.e. not under xterm), I can open and  
plot on a  x11() device but during  demo(rgl)

 > rgl.open()
Error in rgl.open() : rgl.open failed
 > rgl.open

stefano
On 11/dic/06, at 10:51, stefano iacus wrote:

            
#
On 12/10/2006 8:51 PM, stefano iacus wrote:
It's in the .onLoad function in zzz.R:

   if ( .Platform$OS.type == "unix" ) {
     unixos <- system("uname",intern=TRUE)
     if ( unixos == "Darwin" ) {
       # For MacOS X we have to remove /usr/X11R6/lib from the 
DYLD_LIBRARY_PATH
       # because it would override Apple's OpenGL framework
 
Sys.putenv("DYLD_LIBRARY_PATH"=gsub("/usr/X11R6/lib","",Sys.getenv("DYLD_LIBRARY_PATH")))
       if ( .Platform$GUI == "AQUA" &&
            file.exists(system.file("libs", "aglrgl.so", package = 
"rgl"))) {
         initValue <- 1
         rgl <<- "aglrgl"
       }
     }
   }

Does the lib get a different name or sit somewhere else on that system? 
  I have the file.exists test in case someone has configured not to 
build the AGL version, but maybe the filename is wrong.  Do you know a 
safe test to see if the lib exists?
On 12/10/2006 8:56 PM, stefano iacus wrote:
> and, for the standard  shell (i.e. not under xterm), I can open and
 > plot on a  x11() device but during  demo(rgl)
 >
 >  > rgl.open()
 > Error in rgl.open() : rgl.open failed
 >  > rgl.open

The initialization is currently done in .onLoad, and if it fails, no 
additional attempts are made.  I'll see if it's safe to try again.

By the way, did you manually set DISPLAY before you opened the x11 
device?  I get an error in the standard shell when I try that, but 
Sys.putenv fixes it.

Duncan Murdoch
#
Duncan,
I see now. On PPC you should use

    file.exists(system.file("libs/ppc", "aglrgl.so", package ="rgl"))

and, under intel,

    file.exists(system.file("libs/i386", "aglrgl.so", package ="rgl"))

instead of just

    file.exists(system.file("libs", "aglrgl.so", package ="rgl"))

i.e.
    file.exists(system.file(file.path("libs",.Platform$r_arch),  
"aglrgl.so", package ="rgl"))


And yes, you have to explicitly set the DISPLAY var under the shell  
unless you use xterm.

I have only one doubt, which I'm going to verify: if you override the  
DYLD_LIBRARY_PATH var there should be potential problems with tcltk  
which is still x11.

stefano
On 11/dic/06, at 20:49, Duncan Murdoch wrote:

            
#
Duncan,
using
works perfectly for me on ppc. The correct version of the GL is taken  
from R.app and xterm/shell
Maybe you can test on i386

stefano
On 11/dic/06, at 21:12, stefano iacus wrote:

            
#
I forgot to mention, no problem with x11 tcltk.
stefano
On 11/dic/06, at 21:12, stefano iacus wrote:

            
#
On Dec 11, 2006, at 7:12 AM, stefano iacus wrote:

            
you can drop the file.path there i.e.
system.file("libs",.Platform$r_arch,"aglrgl.so", package ="rgl")

and yes, everyone should be careful when using libs, because multi- 
arch builds are now more common (not just on Macs).
Nope - the line is in fact a noop in current versions of R, because  
we no longer set DYLD_LIBRARY_PATH anymore (it was causing too much  
trouble).

Cheers,
Simon

BTW: this is the second message I didn't get from Duncan - is there  
some filtering in place?
#
On 12/dic/06, at 13:46, Simon Urbanek wrote:

            
not on r-sig-mac, if this is what you meant.
stefano
#
Simon Urbanek wrote:
When I do the builds here, I don't get the .Platform$r_arch in the 
path.   (I'm just doing R CMD build, R CMD install *.tar.gz).
So I'll put in a test that looks for the lib in both locations.
I don't know, but the rgl-devel address doesn't seem to be working for 
me.  "neoscientists.net" has recently undergone a lot of renovations, 
and that address may have been messed up.

Bill was questioning the DYLD_LIBRARY_PATH line as well.  I don't really 
know the purpose of it beyond what the comment says:  Daniel put it in 
place a couple of years ago when he added Darwin support.  We currently 
only require R 1.9.0 or better, so I'd rather leave it there if it's 
harmless in current R.

I've just put 
http://www.stats.uwo.ca/faculty/murdoch/temp/rgl_0.69.536.tar.gz online; 
it contains the revised test.  I've also
documented the dangerous function rgl.init(), which redoes the 
initialization (in case you forgot to start X first, this gives
you a second chance).  It's dangerous, because if you have any open rgl 
windows when you call it, they'll be orphaned.  There
might be memory leaks even in other cases, but I'm not going to take the 
time to track them down.

Duncan Murdoch
4 days later
#
On Dec 12, 2006, at 12:22 AM, Duncan Murdoch wrote:

            
.. then you have single-arch build and  .Platform$r_arch should be ''  
and thus the path is still ok - that's what I was trying to say ...
It may be possibly combination of several things - I just got a few  
mails from R-SIG-Mac with a 3-day lag ..
It was actually my patch long time ago - it was necessary when  
DYLD_LIBRARY_PATH contained /usr/X11R6/lib [because that is what we  
do on other unices] which was throwing off the proper library lookup.  
We have fixed R since, so it is no longer needed. (FWIW unlike  
LD_LIBRARY_PATH it is actually effective immediately so the change  
really mattered).
Great job, thanks! It works as advertized (even universal build seems  
to be ok).

Thanks,
Simon