Skip to content

R.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH

13 messages · Tom Schoenemann, Marc Schwartz, Steve Lianoglou +4 more

Original
Tom Schoenemann
# 
Hello,

I am trying to get a custom R package (from another group) to run on my system. If I call it from the command line r, it works fine.  If I call it from R.app, it complains with:

Error in dyn.load(file, DLLpath = DLLpath, ...) : 
  unable to load shared object '/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so':
  dlopen(/Library/Frameworks/R.framework/Versions/3.0/Resources/library/ANTsR/libs/libRantsRegistration.so, 6): Library not loaded: libitkdouble-conversion-4.5.1.dylib
  Referenced from: /Applications/image-processing/ANTsR/src/ANTS/ANTS-build/lib/libl_antsRegistration.dylib
  Reason: image not found
Error: package or namespace load failed for ?ANTsR?

(ANTsR is the package I'm trying to get working)

I CAN get it to work by doing this on the command line first:

export DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib

and then also opening the R.app from the command line:

open /Applications/R.app/

However, I can't seem to get R.app to know about 
export DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib
unless I do it this way. 

So my questions are:

1) how can I get R.app to know about the DYLD_FALLBACK_LIBRARY_PATH?  I tried putting it into my .Renviron file, but it doesn't work  (maybe the syntax is supposed to be different?)

2) why does r on the command line know about dynamic libraries, but R.app does not?? This seems like a bug, but maybe there is a good reason for it?

Thanks for any suggestions,

-Tom
Marc Schwartz
#
On Aug 8, 2013, at 3:42 PM, Tom Schoenemann <toms at indiana.edu> wrote:

            

      
      
      
    

        
In general, OSX GUI based apps do not inherit the shell environment. This is the case with Emacs on OSX for example.

What is the syntax that you used in .Renviron? It should be along the lines of:

  DYLD_FALLBACK_LIBRARY_PATH=/Library/Frameworks/R.framework/Resources/lib

Note, do not use 'export' before the above. I just tried it here and it worked. 

Take a look at ?Startup for more details.

Regards,

Marc Schwartz

  
  


  


      

    

    

      
      

        


  

        

      Steve Lianoglou
    

    

      
      #
    

  


  

      
Hi,

        
On Thu, Aug 8, 2013 at 1:42 PM, Tom Schoenemann <toms at indiana.edu> wrote:

            

      
      
      
    

        
I believe this is due to the phenomenon explained here:
http://stackoverflow.com/questions/135688/setting-environment-variables-in-os-x

Look for the answer that starts with "Up to and including Lion"

Also you'll find a link to a free preference pane you can install that
lets you handle these things with a GUI (pref pane) -- I've never used
it, but you can find it here:

http://diaryproducts.net/EnvPane
https://github.com/hschmidt/EnvPane

You could also try to manually set the environment variable in your
working R session, via:

R> Sys.setenv(DYLD_FALLBACK_LIBRARY_PATH="/Library/Frameworks/R.framework/Resources/lib")

not sure if that'll work, but easy enough to try before.

Still -- it's possible that DYLD vars won't work in this way. See this:
http://support.apple.com/kb/TS4267

Sorry -- no concrete answers here, but hopefully these things will
help you find a workable solution.

-steve

  
    

      
      
    

  


  


      

    

    

      
      

        
      

    

    

      
      

        
      

    

    

      
      

        
      

    

    

      
      

        


  

        

      Brian Ripley
    

    

      
      #
    

  


  

      
R.app is a process. R is a shell script that launches a process.  Both 
inherit the environment they are launched from, but it is usually 
different from the GUI and from a terminal.

It is regarded as a security hole to allow a running process to change 
the settings of its dynamic loader (dyld on OS X), so I would not expect 
that setting such environment variables from within R.app (including 
from reading .Renviron) to affect dyld.  So if it did for Marc, I am 
surprised and would expect that hole to be plugged in due course.

It is not 'R.app doesn't respect DYLD_FALLBACK_LIBRARY_PATH': R.app 
knows nothing about it.  Rather, it is dyld which I would expect to read 
its environment variables only when the process is launched (and as 
Steve Lianoglou has pointed out, which plists are read before dyld is 
initialized for a process has changed over time).

This is not really the best way to extend the library search path.  In 
this case, for one package, the simplest way is to use -rpath when the 
package was installed (and I believe you can set or edit the runpath 
after the .so is made with install_name_tool).

        
On 08/08/2013 22:00, Marc Schwartz wrote:

            

      
      
      
    

        

      
      
    

        

  
    

      
      
    

  


  


      

    

    

      
      

        


  

        

      Berend Hasselman
    

    

      
      #
    

  


  

      
On 08-08-2013, at 22:42, Tom Schoenemann <toms at indiana.edu> wrote:

        

            

      
      
      
    

        
Something similar was reported earlier this year.
See https://stat.ethz.ch/pipermail/r-sig-mac/2013-April/010057.html
In that case the way the package was built was incorrectly.

  
  


  


      

    

    

      
      

        


  

        

      Marc Schwartz
    

    

      
      #
    

  


  

      
Hi all,

Just for clarification, I only set the variable in ~/.Renviron to be sure that it was picked up by R.app, in case Tom had not used the correct syntax. I did not actually install the package under discussion from the source at GitHub, so I cannot confirm that the approach resolved the issue that Tom is reporting. Tom's report would suggest that it does not.

Berend's reply would seem to support the notion that this is a problem in the way in which the package ends up being built, so would lead one down the path, I believe, of a bug in the package, perhaps in its make related files vis-a-vis the included C++ code. Thus a report to the package author would seem to be in order.

With respect to Kasper's reply, there are potential issues in resetting or unsetting DYLD_FALLBACK_LIBRARY_PATH or DYLD_LIBRARY_PATH in that there are other applications that can depend upon their value and if altered, can break those applications. So the caution is warranted.

If Tom is on Mountain Lion, the message:

  "dyld: DYLD_ environment variables being ignored because main executable (/usr/bin/login) is setuid or setgid"

may be related to a known bug in Mountain Lion (OS X 10.8) that occurs when running sudo in a terminal session. It has been widely reported, with various attempts at resolution, including things like creating shell wrappers for sudo, but no definitive solution that lacks side effects has been put forth. Apple appears to know about the bug, since reports would suggest that it has been resolved in beta releases of Mavericks (OS X 10.9), but no official fix is yet pending for Mountain Lion. Perhaps a future update to Mountain Lion might include the fix if the Mavericks solution is stable.

If Tom is not on Mountain Lion, then the problem may yet be related in terms of the underlying etiology in setting DYLD_FALLBACK_LIBRARY_PATH, which brings Kasper's note of caution into consideration.

Regards,

Marc

        
On Aug 9, 2013, at 2:10 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
Sorry for coming in late - I was traveling - otherwise I'd hope to stop this madness earlier :)

Any reason why R for Mac FAQ 12.18 (and the proposed solutions) would not apply here?

I also agree that DYLD_FALLBACK_LIBRARY_PATH should not be messed with and that the proper solution is to fix the libtk*dylib which has bad ID and thus gets linked incorrectly (missing path).

Cheers,
Simon

        
On Aug 8, 2013, at 4:42 PM, Tom Schoenemann wrote:

        

            

      
      
      
    

        

      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Tom Schoenemann
    

    

      
      #
    

  


  

      
You may not have read the whole thread.

        
On Aug 8, 2013, at 5:18 PM, Tom Schoenemann <toms at indiana.edu> wrote:

        

            

      
      
      
    

        
The reason seems to be:

        
On Aug 9, 2013, at 3:10 AM, Prof Brian Ripley <ripley at stats.ox.ac.uk> wrote:

        

            

      
      
      
    

        
Regarding why this package requires DYLD_FALLBACK_LIBRARY_PATH to be set to work via GUI is something that I don't understand myself, but will certainly pass on your comments to the package maintainers.

Regarding the dangers some of you see of using DYLD_FALLBACK_LIBRARY_PATH in this way, can anyone elaborate in a way that a package user like myself can appreciate?  How exactly could it wreck my system? Given that this package is extremely useful to my research, I'm willing to chance it if it only means odd messages in the terminal. If my disk gets wiped, I might be more concerned.

Thanks for any help you can provide to enlighten me more (this has been very enlightening so far).

-Tom

        
On Aug 9, 2013, at 5:12 PM, Simon Urbanek <simon.urbanek at r-project.org> wrote:

        

            

      
      
      
    

        

      
      
    

            

      
      
      
    

  
  


  


      

    

    

      
      

        


  

        

      Simon Urbanek
    

    

      
      #
    

  


  

      
On Aug 9, 2013, at 5:40 PM, Tom Schoenemann wrote:

        

            

      
      
      
    

        
I did but apparently you didn't read my answer -- just for clarification 12.18 is from
http://r.research.att.com/man/RMacOSX-FAQ.html
in 3.0 release FAQ it is under number 10.13 (unfortunately someone broke the numbering recently).

Cheers,
S