On Feb 28, 2019, at 00:43, Roy Mendelssohn - NOAA Federal via R-SIG-Mac <r-sig-mac at r-project.org> wrote:
BTW - I should add that my memory is that there is at least one package for having R interact with Python that does an Anaconda install without you really knowing it. Personally I consider that bad practice. It may be more convenient but can lead to unexpected trouble down the line just because of issues like this. I have also seen R and Julia packages install things under the covers using Homebrew. I also consider this bad practice, again because it can lead to conflicts that leave the user bewildered . (Homebrew installs is its own directory, but you must be careful about setting Paths, and path priority). This was particularly true when building from source.
I have submitted to CRAN and while it can be an utter pain in the butt, I also appreciate what CRAN does for users of the package - they can install with reasonable assurance that the needed pieces will work together and there won't be any hidden gotchas, and that is worth a lot to users, at least in my experience. I recently spent a week in hell with conda-forge where different packages used the same library (by name) but the recipes installed different versions, and they kept on crashing each other.
So the tl;dr version is you likely installed a package for interop between R and Python, say from source or Github, and undercover it installed Anaconda. And as people have mentioned, Anaconda has its own R environment, which may or may not interfere with the standard R install. I check my .profile or .bash_profile after installs just in case. If there is a setting I will need to use some software, I move that to a separate file to be sourced when needed. Since I have started doing that, a lot of conflicts have disappeared.
HTH,
-Roy
On Feb 27, 2019, at 6:09 PM, Roy Mendelssohn - NOAA Federal <roy.mendelssohn at noaa.gov> wrote:
You are welcome (my one good deed for the day - I guess I can go to bed now!!!) Anaconda is a great product, I use it for my Python work, they actually ask you if you want them to modify the .profile, but people say yes without realizing the implications. First time I installed it, I said yes but then looked at what was added to the file, and realized that could cause conflicts. But since it is so easy to copy that part to another file and then source it as needed, you can keep things separate. One of the main things is anything in /usr/bin and /usr/local/bin that had similar things in Anaconda were finding the Anaconda version.
-Roy
On Feb 27, 2019, at 5:57 PM, robin hankin <hankin.robin at gmail.com> wrote:
Roy, thanks for this! Your insight explains a great deal of my
problems. And indeed I see a whole bunch of PATH additions which were
created by anaconda (these are in .bash_profile, certainly not put
there by me!).
Just to clarify, I'm not using anaconda by choice, it seems to have
been installed inadvertently.
stop press: configure works! Thanks!
Best wishes
Robin
hankin.robin at gmail.com
hankin.robin at gmail.com
On Thu, Feb 28, 2019 at 2:47 PM Roy Mendelssohn - NOAA Federal via
R-SIG-Mac <r-sig-mac at r-project.org> wrote:
Anaconda adds code to the end of your ,.profile that can really play havoc with paths in other programs/settings - and off I remember correctly it puts the changes at the front of your $PATH.. I moved that code in .profile to a separate file. When I want anaconda, I just source the file. Makes problems such as that described much less likely. If you are using iTerm2 or the like, then you can easily have a tab with the Anaconda paths and the rest of the tabs the more "usual" paths.
HTH,
-Roy
On Feb 27, 2019, at 5:32 PM, Simon Urbanek <simon.urbanek at R-project.org> wrote:
That's anaconda - they don't include paths which is why it breaks everything until you insert a manual override via DYLD_LIBRARY_PATH. See Robin's e-mail he is NOT using the system curl, but rather a custom version from anaconda ("/Users/rhankin/anaconda3/lib").
Cheers,
Simon
On Feb 25, 2019, at 04:28, peter dalgaard <pdalgd at gmail.com> wrote:
Hmm, how did "@rpath" get in there? I don't see it anywhere in my build and source dirs. Looks like something that should have been substituted (by perl?) with the appropriate path.
Is your library (...anaconda3/lib) correctly installed? I have, for the system libcurl:
pd$ ls -l /usr/lib/*curl*
lrwxr-xr-x 1 root wheel 15 Nov 14 14:36 /usr/lib/libcurl.3.dylib -> libcurl.4.dylib
-rwxr-xr-x 1 root wheel 854208 Nov 30 08:37 /usr/lib/libcurl.4.dylib
lrwxr-xr-x 1 root wheel 15 Nov 14 14:36 /usr/lib/libcurl.dylib -> libcurl.4.dylib
-pd
On 25 Feb 2019, at 01:28 , robin hankin <hankin.robin at gmail.com> wrote:
thanks for this Peter, my config.log file looks like this:
configure:42615: result: yes
configure:42629: checking if libcurl is version 7 and >= 7.22.0
configure:42658: gcc -o conftest -g -O2
-I/Users/rhankin/anaconda3/include -I/usr/local/include
-I/usr/local/include -L/usr/local/lib conftest.c
-L/Users/rhankin/anaconda3/lib -lcurl -lssh2 -lssh2 -lssl -lcrypto
-lssl -lcrypto -lgssapi_krb5 -lresolv -lz -L/usr\
/local/lib -lpcre2-8 -lpcre -llzma -lbz2 -lz -licucore -ldl -lm -liconv >&5
configure:42658: $? = 0
configure:42658: ./conftest
dyld: Library not loaded: @rpath/libcurl.4.dylib
Referenced from: /Users/rhankin/Downloads/R-devel/./conftest
Reason: image not found
./configure: line 2254: 73408 Abort trap: 6 ./conftest$ac_exeext
configure:42658: $? = 134
configure: program exited with status 134
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "R"
| #define PACKAGE_TARNAME "R"
Best wishes
Robin
hankin.robin at gmail.com
hankin.robin at gmail.com
On Mon, Feb 25, 2019 at 11:41 AM peter dalgaard <pdalgd at gmail.com> wrote:
It doesn't usually happen on 10.13.6... Best guess is that somehow you are picking up an older library (e.g. in /usr/local/lib) even if you are using curl-config from a newer version.
The detective work needed could take off from config.log, region around this:
configure:39937: checking if libcurl is version 7 and >= 7.22.0
configure:39966: gcc -arch x86_64 -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib conftest.c -lcurl -lpcre -llzma -lbz2 -lz -licucore -lm -liconv >&5
configure:39966: $? = 0
configure:39966: ./conftest
configure:39966: $? = 0
configure:39976: result: yes
That's for a succesful build, a failed one will usually give more info including the failing program code.
-pd
On 24 Feb 2019, at 22:45 , robin hankin <hankin.robin at gmail.com> wrote:
Hi, macos 10.13.6, trying to compile 3.6.0, revision 76152.
./configure
[snip]
checking for curl-config... /Users/rhankin/anaconda3/bin/curl-config
checking libcurl version ... 7.63.0
checking curl/curl.h usability... yes
checking curl/curl.h presence... yes
checking for curl/curl.h... yes
checking if libcurl is version 7 and >= 7.22.0... no
configure: error: libcurl >= 7.22.0 library and headers are required
with support for https
if we have libcurl 7.63, as it says in the output, why the error? How
to proceed?
hankin.robin at gmail.com