When I try to load library("rJava") in RStudio on OsX High Sierra, I get the error already mentioned about the image not being present:
Error: package or namespace load failed for 'rJava':
.onLoad failed in loadNamespace() for 'rJava', details:
call: dyn.load(file, DLLpath = DLLpath, ...)
error: unable to load shared object '/Users/ognjenmilicevic/RPlay/Methylation_Mayo_Vesna_Garovic/libs/rJava/libs/rJava.so':
dlopen(/Users/ognjenmilicevic/RPlay/Methylation_Mayo_Vesna_Garovic/libs/rJava/libs/rJava.so, 6): Library not loaded: /Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/server/libjvm.dylib
Referenced from: /Users/ognjenmilicevic/RPlay/Methylation_Mayo_Vesna_Garovic/libs/rJava/libs/rJava.so
Reason: image not found
I tried reconfiguring Java but the error persists:
$ R CMD javareconf
Java interpreter : /usr/bin/java
Java version : 10.0.1
Java home path : /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
Java compiler : /usr/bin/javac
Java headers gen.: /usr/bin/javah
Java archive tool: /usr/bin/jar
trying to compile and link a JNI program
detected JNI cpp flags : -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/darwin
detected JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
clang -I"/Library/Frameworks/R.framework/Resources/include" -DNDEBUG -I/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/include -I/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/include/darwin -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk -I/usr/local/include -fPIC -Wall -g -O2 -c conftest.c -o conftest.o
clang -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/Library/Frameworks/R.framework/Resources/lib -L/usr/local/lib -o conftest.so conftest.o -L/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/lib/server -ljvm -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
JAVA_HOME : /Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home
Java library path: $(JAVA_HOME)/lib/server
JNI cpp flags : -I$(JAVA_HOME)/include -I$(JAVA_HOME)/include/darwin
JNI linker flags : -L$(JAVA_HOME)/lib/server -ljvm
Updating Java configuration in /Library/Frameworks/R.framework/Resources
Done.
Removing and reinstalling the package doesn't help. I tried pointing to my version by using:
dyn.load('/Library/Java/JavaVirtualMachines/jdk-10.0.1.jdk/Contents/Home/lib/server/libjvm.dylib')
The error persists. All the while it works in R when ran as a command. Where is the path "/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/server/libjvm.dylib" coming from and how can I change it to point to my installation?
It looks like you have sort of a messy installation or rJava.
You can always check which version of Java was used (while building rJava) by calling:
> otool -L /Library/Frameworks/R.framework/Resources/library/rJava/libs/rJava.so
/Library/Frameworks/R.framework/Resources/library/rJava/libs/rJava.so:
rJava.so (compatibility version 0.0.0, current version 0.0.0)
/Library/Java/JavaVirtualMachines/jdk-11.0.1.jdk/Contents/Home/lib/server/libjvm.dylib (compatibility version 1.0.0, current version 1.0.0)
/Library/Frameworks/R.framework/Versions/3.6/Resources/lib/libR.dylib (compatibility version 3.6.0, current version 3.6.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1259.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
in your case you have to call
> otool -L /Users/ognjenmilicevic/RPlay/Methylation_Mayo_Vesna_Garovic/libs/rJava/libs/rJava.so
Make sure you have this Java version installed: jdk-11.0.1.jdk. If you don't have it, and you want to install rJava with your current release of JDK - e.g.: jdk-10.0.1.jdk, follow the steps here: http://www.owsiak.org/r-java-11-and-making-sure-you-can-load-rjava/
Also, remember that in macOS, the default Java is the newest one. It means that RStudio will pick the version with highest number - one that is enabled.
You can disable given version of Java by calling
> cd /Library/Java/JavaVirtualMachines/jdk-11.0.4.jdk/Contents
> mv Info.plist Info.plist~
Above commands will make this Java version "invisible" for macOS.
Once you follow the steps (as described in linked article) you will be able to run Java from both: R and RStudio
> R
R version 3.6.1 (2019-07-05) -- "Action of the Toes"
Copyright (C) 2019 The R Foundation for Statistical Computing
Platform: x86_64-apple-darwin15.6.0 (64-bit)
R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.
Natural language support but running in an English locale
R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.
Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.
> library(rJava)
> .jinit()
> J("java.lang.System","getProperty","java.version")
[1] "11.0.3"
>
Related
I am trying to statically link the libraries while compiling a C++ program.
g++ (GCC) 4.8.5 20150623 (Red Hat 4.8.5-4)
$ g++ -std=c++11 -I/home/jerry/Desktop/tiny-dnn -m32 -pthread -static train.cpp -o train
/usr/bin/ld: cannot find -lstdc++
/usr/bin/ld: cannot find -lm
/usr/bin/ld: cannot find -lpthread
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
I found this post
(/usr/bin/ld: cannot find -lc while compiling with makefile ) that says to to install glibc-static.
bash-4.2# sudo yum install glibc-static
Loaded plugins: langpacks
ol7_UEKR3 | 1.2 kB 00:00:00
ol7_latest | 1.4 kB 00:00:00
No package glibc-static available.
Error: Nothing to do
bash-4.2# yum info glibc-static
Loaded plugins: langpacks
Error: No matching Packages to list
bash-4.2# yum search glibc
Loaded plugins: langpacks
================================================== N/S matched: glibc ===================================================
glibc-common.x86_64 : Common binaries and locale data for glibc
compat-glibc.x86_64 : Compatibility C library
compat-glibc-headers.x86_64 : Header files for development using standard C libraries.
glibc.i686 : The GNU libc libraries
glibc.x86_64 : The GNU libc libraries
glibc-devel.i686 : Object files for development using standard C libraries.
glibc-devel.x86_64 : Object files for development using standard C libraries.
glibc-headers.x86_64 : Header files for development using standard C libraries.
glibc-utils.x86_64 : Development utilities from GNU C library
kdesdk-kmtrace.x86_64 : Assist with malloc debugging using glibc's "mtrace" functionality
kernel-headers.x86_64 : Header files for the Linux kernel for use by glibc
latrace.i686 : LD_AUDIT feature frontend for glibc 2.4+
latrace.x86_64 : LD_AUDIT feature frontend for glibc 2.4+
Name and summary matches only, use "search all" for everything.
How can I install glibc-static? Please help.
Thanks.
glibc-static is only available in the Optional channels. RPM packages in the Optional channels are officially unsupported, which is why these channels are not enabled by default.
The exact command to enable optional channels depends on the product variant. Something like
subscription-manager repos --enable=rhel-7-server-optional-rpms
could work, but the details depend on your environment (and it's more a sysadmin than a programming matter at this point).
Note: There is are very good reasons why static linking is not supported by Red Hat. You really should avoid it.
I had this issue in the Docker container for Centos 8. I found that the following worked:
dnf --enablerepo=powertools install glibc-static
This was suggested from this packages site
you should user glibc-static to compile static bin
I'm trying to compile cmake version 3.0.2 on GCC 4.9.2 but I'm getting the error message
/home/DrNo/cmake-3.0.2/Bootstrap.cmk/cmake: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /home/DrNo/cmake-3.0.2/Bootstrap.cmk/cmake)
---------------------------------------------
Error when bootstrapping CMake:
Problem while running initial CMake
I've taken a look at the ABI strings(?) in libstdc++.so.6 and can't find GLIBCXX_3.4.15:
$ strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX
GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH
I've tried cmake compiling versions 3.0.0, 3.0.1, 3.0.2 and 3.7.2 but all require GLIBCXX_3.4.15, so it looks like I'm going to have to upgrade my version of GCC on this system (CentOS), which I don't want to because I've built this project on another system (Ubuntu with prepackaged cmake 3.0.2) with GCC 4.9.2.
Is it possible to have two GCC installs. A more recent one to build cmake and GCC 4.9.2 to build the rest of the project.
I hope you managed to get rid of the problem i am just leaving this comment here as a future reference:
I did have a similar problem when compiling cmake version 3.10.0 on gcc4.1.2 . I looked at my LD_LIBRARY_PATH and saw that there was a path from a former gcc version.
I simply set it to the correct path something along the lines gcc_4.1.2/linux50_64/lib64 via setenv. Nifty trick I learned was using setenv LD_LIBRARY_PATH ${LD_LIBRARY_PATH}/your/path/here: which basically appends your path to the everything inside LD_PATH_LIBRARY variable.
Summary
When linking an executable with a dylib, is install_name_tool the only way to make the dylib path relative to the executable, or is there a way of doing so in clang's linking step?
Setup
Given the following project structure:
- Project Root
| compile.sh
- lib_src
| myprint.cpp
| myprint.h
- main_src
| main.cpp
with these files: https://gist.github.com/JohannesMP/8fa140b60b8ffeb2cae0
Running compile.sh (used instead of a make file for simplicity's sake here) results in the following files:
- Project Root
| main (a unix executable linked to myprint.dylib)
| myprint.dylib (a dynamic library that main uses)
Running the program with ./main while cd'd into the project works fine, but attempting to run it from anywhere else, such as by simply double clicking it, will result in the following error:
dyld: Library not loaded: myprint.dylib
Referenced from: /Users/Jo/Sandbox/libtest/main
Reason: image not found
Trace/BPT trap: 5
When inspecting main with otool I can see that this is because the path for myprint.dylib is not defined in terms of the executable:
$ otool -L main
main:
myprint.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)
The general fix
As far as I've been able to find out, the suggested way to fix this is by using install_name_tool -change and modify the path to use #executable_path:
install_name_tool -change myprint.dylib #executable_path/myprint.dylib main
The Question
While the above fix clearly works, it seems somewhat unintuitive to me that there is no way of telling clang to just link main in such a way that it already uses the #executable_path to start with. It seems odd that when compiling a program with an arbitrary number of dylibs, that this has to be done for every single one.
Is this really the only way? Is this what cmake and xcode do under the hood? Is there a reason why we can't just have clang++ link relatively rather than absolutely by default?
I have found some tools that make the process easier, such as the mac dylib bundler, but I'm curious if anyone has any insight as to why it is done this way.
TL;DR
Is there a way to change just this line to avoid having to run install_name_tool -change?
It is indeed possible:
When compiling my library I set its install_name to be in terms of #rpath:
clang++ -dynamiclib lib_src/myprint.cpp -o myprint.dylib -install_name #rpath/myprint.dylib
And then in when compiling the executable I set rpath to be in terms of #executable_path, which can be done in a single step:
clang++ main_src/main.cpp -o main -I ./lib_src myprint.dylib -rpath #executable_path
For a detailed explanation of #rpath and #executable_path please check this wiki: https://wincent.com/wiki/#executable_path,_#load_path_and_#rpath
I'm completely new to Mac OS X and the main reason why I bought my new MacBook Pro R15 Retina Edition is to start studying CUDA API.
But I can't get my project build.
For example, when I create a new CUDA project, I go in the project properties and make the following changes :
Compiler for C/C++/Objective-C : LLVM GCC 4.2
Other Linker Flag : -lcuda, -lcudart
Header Search Path : /usr/local/cuda/include
Library Search Path : /usr/local/cuda/lib
When I start adding the necessary libraries in my code, everything runs fine. My code gets no typing error.
When I build the project, I get linking errors (paths shortened and message broken up for readability):
Ld /my_test_project/Build/Products/Debug/test normal x86_64 cd /Users/Admin/Documents/test setenv MACOSX_DEPLOYMENT_TARGET 10.7 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++
-arch x86_64
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
-L/my_test_project/Build/Products/Debug
-L/usr/local/cuda/lib -F/my_test_project/Build/Products/Debug
-filelist /my_test_project/Build/Intermediates/test.build/Debug/test.build/Objects-normal/x86_64/test.LinkFileList
-mmacosx-version-min=10.7
-lcudart
-lcuda
-o /my_test_project/Build/Products/Debug/test
ld: file not found: #rpath/CUDA.framework/Versions/A/CUDA for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation)
What's weird, is that when I go to the described path, I see the CUDA executable. The file is there!
When I use the cuComplex.h, which uses the library, every single mathematical expression (such as log, cos, sin, etc...) is an "undefined variable". However, the cuComplex.h library has inside it the library.
The driver, the SDK and toolkit are well installed and everything works like a charm. I can get the SDK examples working. But I think I miss a detail to get the whole thing working.
I have the same problem with CUDA 5.0 and Xcode 4.4.1 installed on Mountain Lion. The reason is that libcuda.dylib links CUDA.framework with rpath, which you can inspect with otool.
otool -L /usr/local/cuda/lib/libcuda.dylib
/usr/local/cuda/lib/libcuda.dylib:
/usr/local/cuda/lib/libcuda.dylib (compatibility version 1.1.0, current version 5.0.17)
#rpath/CUDA.framework/Versions/A/CUDA (compatibility version 1.1.0, current version 5.0.17)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.0)
However, Xcode does not seem to recognize CUDA.framework under /Library/Frameworks. The reason is unknown. You have to add it yourself to your project.
In your project property page, click Build Phases -> Link with Libraries. Select CUDA.framework. Add it using "Add Others" if it does not appear in the list. This way you get it linked.
If you are writing Makefiles, you want to add this to fully automate the linking stage:
-F/Library/Frameworks -framework CUDA
As an alternative that worked better for my setup is to change the path at libcuda like this:
sudo install_name_tool -change #rpath/CUDA.framework/Versions/A/CUDA \
/Library/Frameworks/CUDA.framework/CUDA \
/usr/local/cuda/lib/libcuda.dylib
As usual, don't paste a sudo command into your terminal if you don't understand what it does.
I had the same problem compiling the CUDA 6.5 examples on OS X 10.10, with Xcode 6.1. The problem happened in the examples whose Makefiles contained the line:
ALL_LDFLAGS += -Xlinker -framework -Xlinker CUDA
The fix was to tell the linker about /Library/Frameworks, so that the above was replaced with 2 lines:
ALL_LDFLAGS += -Xlinker -F/Library/Frameworks
ALL_LDFLAGS += -Xlinker -framework -Xlinker CUDA
Presumably your question is answered at this point, but this page is almost literally the only google result for "ld: framework not found CUDA" and hopefully this can save others some time.
I had a similar CUDA linking issue with CUDA 8.0 and OSX 10.12 while compiling the sample files. Adding the following to the make files solved the problem.
LDFLAGS += -Xlinker -F/Library/Frameworks
My application builds and runs fine on 10.6. I have Base SDK set to 10.6 and Mac OS X Deployment Target set to 10.5.
My application uses the system libcurl.dylib — instead of adding the dylib to the project, I just add -lcurl to the linker flags in build settings. (Though I have tried it both ways.)
When I launch the application on 10.5.8, I get the following error
Dyld Error Message: Library not loaded: /usr/lib/libcurl.4.dylib
Referenced from: /Applications/My Application.app/Contents/MacOS/MyApplication
Reason: Incompatible library version:
MyApplication requires version 6.0.0 or
later, but libcurl.4.dylib provides
version 5.0.0
Sure enough, if I otool -L the application's binary, I get the following for libcurl:
/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
Is there any way around this, or should I just statically link my own libcurl build?
Have you tried setting the Base SDK to 10.5 as well?
$ otool -L /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libcurl.4.dylib
/Developer/SDKs/MacOSX10.6.sdk/usr/lib/libcurl.4.dylib:
/usr/lib/libcurl.4.dylib (compatibility version 6.0.0, current version 6.1.0)
...]
$ otool -L /Developer/SDKs/MacOSX10.5.sdk/usr/lib/libcurl.4.dylib
/Developer/SDKs/MacOSX10.5.sdk/usr/lib/libcurl.4.dylib:
/usr/lib/libcurl.4.dylib (compatibility version 5.0.0, current version 5.0.0)
[...]