This is now resolved. The main clue from from the "Understanding R's Startup" article linked above, where @slopp mentions that RStudio "doesn’t 'start' R, it uses R as a library, either as a DLL on Windows or as a shared object on Mac and Linux." This is intriguing, because it suggests that there may be different binaries involved for each environment. This seems to matter for run-path dependent libraries.
It turns that that the Oracle ODBC driver does use @rpath
, here is the (partial) output from otool -l libsqora.dylib.12.1
:
Load command 3
cmd LC_ID_DYLIB
cmdsize 56
name @rpath/libsqora.dylib.12.1 (offset 24)
time stamp 1 Wed Dec 31 19:00:01 1969
current version 0.0.0
compatibility version 0.0.0
...
Load command 12
cmd LC_LOAD_DYLIB
cmdsize 56
name @rpath/libclntsh.dylib.12.1 (offset 24)
time stamp 2 Wed Dec 31 19:00:02 1969
current version 0.0.0
compatibility version 0.0.0
Load command 13
cmd LC_LOAD_DYLIB
cmdsize 56
name @rpath/libodbcinst.2.dylib (offset 24)
time stamp 2 Wed Dec 31 19:00:02 1969
current version 3.0.0
compatibility version 3.0.0
Load command 14
cmd LC_RPATH
cmdsize 48
path @executable_path/../../oracle/lib (offset 12)
My understanding is that the value of @rpath
at the time libsqora.dylib.12.1
is loaded will determine whether these libraries can be found. I made the following changes:
install_name_tool -id "/usr/local/opt/instantclient-basic/lib/libsqora.dylib.12.1" libsqora.dylib.12.1
install_name_tool -change "@rpath/libodbcinst.2.dylib" "/usr/local/lib/libodbcinst.2.dylib" libsqora.dylib.12.1
install_name_tool -change "@rpath/libclntsh.dylib.12.1" "/usr/local/lib/libclntsh.dylib.12.1" libsqora.dylib.12.1
install_name_tool -rpath "@executable_path/../../oracle/lib" "/usr/local/lib" libsqora.dylib.12.1
where /usr/local/opt/instantclient-basic/lib
is the location of libsqora.dylib.12.1
.
So, I turned all the run-paths into absolute paths, and that seems to have fixed it. Everything is now working in (command-line) R, as well as RStudio, including knitting R Markdown.