Fails testing - Library not loaded: libboost_regex.dylib about uap-r

[Ironholds]

Yeah, I've been encountering a similar issue, and I'm not sure why. I'll try to look into it next week.

[btskinner]

I have an update. I was able to install and load the package after adding symbolic links for libboost_regex.dylib and libboost_system.dylib to /Library/Frameworks/R.framework/Libraries (which I guess is itself a link to /Library/Frameworks/R.framework/Versions/Current/Resources/lib). Both libraries are installed in /usr/local/lib, which is in the environment path, but this was what it took to get everything working. Package successfully loaded and tested on some user agent strings. Thanks!

[Ironholds]

NP! Hmn. Is it a problem with the makefile? i.e., should this lib be looking in more places? I'm not sure how much we can modify Rcpp imports, unfortunately, but if I can I will.

[btskinner]

We're at the edges of my programming ability here, so I'm not sure how much I can help. Rcpp loads fine on my machine and did before this, so the way it does things is probably okay. I did notice this section in the R Installation and Administration manual (6.3.6):

On OS X the primary mechanism is to embed the absolute path to dependent dynamic libraries into an object when it is compiled. Few R packages arrange to do so, but it can be edited via install_name_tool — that only deals with direct dependencies and those would also need to be compiled to include the absolute paths of their dependencies. If the choice of absolute path is to be deferred to load time, how they are resolved is described in man dyld: the role of LD_LIBRARY_PATH is replaced on OS X by DYLD_LIBRARY_PATH and latterly DYLD_FALLBACK_LIBRARY_PATH. Running R CMD otool -L on the package shared object will show where (if anywhere) its dependencies are resolved. DYLD_FALLBACK_LIBRARY_PATH is preferred (and it is that which is manipulated by the R script), but as from 10.11 (‘El Capitan’) the default behaviour had been changed for security reasons to discard these environment variables when invoking a shell script (and R is a shell script). That makes the only portable option to set R_LD_LIBRARY_PATH in the environment, something like

export R_LD_LIBRARY_PATH="R RHOME/lib:/opt/local/lib"

I R CMD INSTALL --no-test-load the package and ran otool -L uaparser.so to confirm that, at least for me, all other libs were being linked, but the two boost *.dylibs weren't. I tried adding /usr/local/lib, where they are located, to R_LD_LIBRARY_PATH. I could see the path when I did a Sys.getenv() in R, but the installer didn't seem to be linking to it. Hence my manual symlinks. Since then, I realized that I spelled it incorrectly and fixed it; after that I was able to install the package without needing the symlinks.

I don't know the standard install paths for boost libraries, but at the moment it seems that one either needs those two lib files in the R fallback path (above) or have them added to the R_LD_LIBRARY_PATH in ~/.bash_profile.

[Ironholds]

Would you rather have it (a) work on Windows or (b) have full compatibility with the range of regexes used?

Basically it's not possible (or: exceedingly hard) to integrate with boost regex on every platform, but C++11 has regex support and now works there, so I can fall back to that - the problem being that it uses different syntax (EMACscript versus PCRE).

[btskinner]

Trying to get my head wrapped around this again. Could you use the BH package as a dependency? The README list of available libraries doesn't include system or regex, but I think the header files might be in there.

[Ironholds]

Alas, no - it needs linking (which is system-dependent) to work.

On Monday, 25 July 2016, Benjamin Skinner [email protected] wrote:

Trying to get my head wrapped around this again. Could you use the BH
https://cran.r-project.org/web/packages/BH/index.html package as a
dependency? The README list of available libraries doesn't include system
or regex, but I think the header files might be in there
https://github.com/eddelbuettel/bh/tree/master/inst/include/boost.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#10 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACXz3sgu6BKrKDc9P2btbGybBfPiBO7fks5qZK41gaJpZM4HZwSg
.

[btskinner]

Reading the BH info a little more closely, I see that now. That's unfortunate. While I personally don't care that much about Windows support, it's probably better to go with (b).