R help - Oct 2006 - [Mac OS X 10.4] object R_loess_raw not found (reason found)

Well... this may be a red herring after all, but it's an interesting one!

It turns out I have got DYLD_LIBRARY_PATH set. This gets exported to R
(or rather, affects the loader that loads the R process?), and somehow
mixes up the way symbols are exported. Something that applies to
launching R from the command line (/usr/bin/R) AND via LaunchServices
(open -a R). Once I noticed that invoking the R GUI like that also
provoked the issue, I quickly understood that something in the
environment must be involved.

Unsetting DYLD_LIBRARY_PATH restores normal behaviour.

Note that this never caused any problems on 10.3 (and I'm not
completely convinced there hasn't been a recent update to dyld that
may be the culprit).

I still don't understand how this could make a symbol unavailable that
is stored in some sort of internal registry.

However, while rebuilding 2.3.1 from source (!, but this one worked
for me), I did notice that the configure script doesn't correctly
detect that gcc-4.0 knows of the visibility attributes. This *may*
somehow be related.

On 09/10/06, Ren? J.V. Bertin <rjvbertin at gmail.com>
wrote:
> To make things even weirder, everything seems to work just fine when I
> launch R via the v1.17 3878 build of the R GUI for 2.4 ...
>

Dinner time with a nice bit of red is a great occasion to ponder over
this sort of thing.

It turns out that I had added a path to my DYLD_LIBRARY_PATH that held
my own stats.so and constants.so . The former must explain why R's
stats.so didn't load, the latter why I had similar problems with a
Python package.

It still bugs me why this was never a problem under 10.3 ...

How does R load the .so files in its packages? It looks like even if a
full path is specified in the file argument to dlopen(), it gets
beaten by whatever there is in DYLD_LIBRARY_PATH. That reeks of
something buggy (or interestingly different) in dlopen or whatever
call is being used, no?

On 09/10/06, Ren? J.V. Bertin <rjvbertin at gmail.com>
wrote:
> Well... this may be a red herring after all, but it's an interesting
one!
>
> I still don't understand how this could make a symbol unavailable that
> is stored in some sort of internal registry.
>