So I'm using the new Bash on Ubuntu on Windows shell, and installed the clisp package to mess with Common Lisp. I get this error when I try clisp test.clisp:
/usr/lib/clisp-2.49/base/lisp.run: error while loading shared libraries: libavcall.so.0: cannot enable executable stack as shared object requires: Invalid argument
This is an entirely fresh install too. I looked in /usr/lib and found the libavcall.so.0 file, but I'm not sure what to do with it. How do I fix this issue?
This issue no longer exists with libffcall 2.0 or newer. It was fixed through this commit.
If you are still using libffcall 1.x: The FAQ (cited by user #cybevnm) explains most of it:
libavcall.so is flagged as requiring executable stack (property GNU_STACK has the value RWE), although it does not need an executable stack. This occurs because it was compiled from assembly-language source code.
You can remove this flag through a command such as sudo execstack -c /usr/lib/libavcall.so.0.
Related
I am a little bit confused on how to efficiently prepare the R package, so that it will be compatible across all needed system platforms. This is needed so that the new version of package will be accepted by CRAN. The main difficulty comes from compiling external C++ shared library, and optionally CUDA version if the compiler is available. To support this flow I've created specific Makefile, unfortunately using GNU-extensions. It works fine on Linux, OSX and when executed manually via gmake on Solaris. Relevant part is here:
# Checking whether nvcc compiler is available
NVCC_TEST = $(shell basename $(shell which nvcc 2> /dev/null)"")
ifeq ($(NVCC_TEST),nvcc)
ALL_LIBS += libcucubes_gpu.so
ALL_OBJS += $(GPU_OBJS)
ALL_FLAGS += $(GPU_FLAGS)
else
ALL_OBJS += gpu_fallback.o
endif
Turns out that, when running R CMD INSTALL (...) on Solaris, the installation fails on something like this:
make: Fatal error in reader: Makefile, line 39: Unexpected end of line seen
ERROR: compilation failed for package 'libcucubes'
As it turns out, it is caused by the fact that Solaris' version of make is executed instead of GNU-compatible gmake (I've tested it works fine), even though it is available. My question is whether there is any simple way to force usage of gmake here, for the R package build. In general I know I could use autotools to solve compatibility issues during installation, but it seems to bring too much complexity for that simple case. Any advices will be really appreciated, thanks!
If you can't get your build process to use gmake instead of Solaris's pure POSIX make, you can use this hack:
Make a dedicated directory for this hack: mkdir $HOME/make_hack
Softlink gmake asmakein that directory: ln -s /path/to/gmake $HOME/make_hack/make
Set your PATH: PATH=$HOME/make_hack:$PATH
Now, run your build process using that PATH, and it should use gmake. Hopefully it just uses make from its PATH envval and not some hardcoded full path.
Yeah, it's a hack. But it's probably a lot easier than modifying the build process to use gmake instead of make.
From Writing R Extensions:
If you really must require GNU make, declare it in the DESCRIPTION
file by
SystemRequirements: GNU make
and ensure that you use the value of environment variable MAKE (and
not just make) in your scripts.
configure scripts are the preferred solution though. BTW, in general a Makevars file is also preferred over a full Makefile.
I compiled my program with gcc using openssl crypto library.
I moved the executable to an other system, and after installing openssl tried to run it. I got the following error:
error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory
What I understand from the following the library is present, but has another name:
locate libcrypto
/usr/lib64/.libcrypto.so.1.0.2f.hmac
/usr/lib64/.libcrypto.so.10.hmac
/usr/lib64/libcrypto.so
/usr/lib64/libcrypto.so.1.0.2f
/usr/lib64/libcrypto.so.10
/usr/lib64/pkgconfig/libcrypto.pc
Can I somehow tell the binary to use one of the present libraries? Or is there a way to install the one which is required?
The compilation was done on Ubuntu 15.10 64 bit, tried to run on Fedora 4.2.3-300.fc23.x86_64.
Can I somehow tell the binary to use one of the present libraries?
No, you can't: there is a reason these libraries have a different name: they are not ABI-compatible. If you managed to somehow tell the binary to use the other library, the result will be a crash if you are lucky, or a silent corruption if you are not.
(BTW, you can try this by creating a symbolic link: ln -s libcrypto.so.1.0.2f libcrypto.so.1.0.0, but you've been warned not to do this).
is there a way to install the one which is required?
Sure: you should be able to copy libcrypto.so.1.0.0 from Ubuntu machine to Fedora one, assuming you can't find a Fedora package that provides it.
When compiling with -fsanitize=memory I get WARNING: Trying to symbolize code, but external symbolizer is not initialized! when running the program. How do I initialize the external symbolizer?
I solved my own problem using MSAN_SYMBOLIZER_PATH=$(which llvm-symbolizer-3.4) ./a.out. The problem is that Ubuntu postfixes the version number but the binary doesn't know that. Of course you need to use MSAN instead of ASAN when using the memory sanitizer.
You are supposed to be able to set the ASAN_FILTER environment variable to point at a symbolizer, but I could not get it to work. However, you can redirect stderr into a symbolizer after the fact. You'll still get the warnings about the uninitialized symbolizer, but the filenames and line numbers will be correct.
You can use asan_symbolizer.py as the external symbolizer. After downloading it from that link (to /tmp, for example), invoke your program like so (in bash, for this example):
./myprogram 2>&1 | /tmp/asan_symbolize.py | c++filt
On my Ubuntu system, the issue is that LLVM's tools are installed under /usr/bin with version suffixes (like llvm-symbolizer-4.0), and the sanitizer tools are looking for them without version suffixes.
LLVM also installs its binaries to, e.g., /usr/lib/llvm-4.0/bin; the tools under /usr/bin are actually just symlinks. So an easy solution is to add the appropriate /usr/lib/llvm-*/bin directory to your path when working with sanitizers.
I received such warning when I run program debug version (compiled with -fsanitize=address) on Linux machine that didn't contain clang installation. The problem disappeared after I installed clang from devtoolset.
Yesterday I removed R2.11 from my system (Win7, 64bit), since I´m working on R2.13.
Since then i get an error message:
> require(rJava)
Lade nötiges Paket: rJava
Error : .onLoad in loadNamespace() fehlgechlagen, Details:
Aufruf: rJava
Fehler: inDL(x, as.logical(local), as.logical(now), ...)
I tried specifying PATH, since I found on the internet that it might have something to do with jvm.dll:
c:\Rtools\bin;
c:\Rtools\perl\bin;
c:\Rtools\MinGW\bin;
c:\Rtools\MinGW64\bin;
C:\Windows\system32;
%R_HOME%\bin;
C:\Program Files\R\R-2.13.0\bin;
C:\Program Files\Java\jre6\bin\server
However I could not solve the problem...
I also can´t run R from the win command line (just type "R"?)
Any suggestions?
Here is some quick advice on how to get up and running with R + rJava on Windows 7 64bit. There are several possibilities, but most have fatal flaws. Here is what worked for me:
Add jvm.dll to your PATH
rJava, the R<->Java bridge, will need jvm.dll, but R will have trouble finding that DLL. It resides in a folder like
C:\Program Files\Java\jdk1.6.0_25\jre\bin\server
or
C:\Program Files\Java\jre6\jre\bin\client
Wherever yours is, add that directory to your windows PATH variable. (Windows -> "Path" -> "Edit environment variables to for your account" -> PATH -> edit the value.)
You may already have Java on your PATH. If so you should find the client/server directory in the same Java "home" dir as the one already on your PATH.
To be safe, make sure your architectures match.If you have Java in Program Files, it is 64-bit, so you ought to run R64. If you have Java in Program Files (x86), that's 32-bit, so you use plain 32-bit R.
Re-launch R from the Windows Menu
If R is running, quit.
From the Start Menu , Start R / RGUI, RStudio. This is very important, to make R pick up your PATH changes.
Install rJava 0.9.2.
Earlier versions do not work! Mirrors are not up-to-date, so go to the source at www.rforge.net: http://www.rforge.net/rJava/files/. Note the advice there
“Please use
`install.packages('rJava',,'http://www.rforge.net/')`
to install.”
That is almost correct. This actually works:
install.packages('rJava', .libPaths()[1], 'http://www.rforge.net/')
Watch the punctuation! The mysterious “.libPaths()[1],” just tells R to install the package in the primary library directory. For some reason, leaving the value blank doesn’t work, even though it should default.
I finally solved the problem:
It seems that rJava searches for jvm.dll in ~\Java\jre6\bin\client.
However this folder didn´t exist on my system (jvm.dll was in ~\bin\server).
So I just made a copy of jvm.dll in a folder ~\bin\client\ and added this to the path.
Now everything works fine!
My problem was solved by
install.packages("SqlRender",INSTALL_opts="--no-multiarch")
It was a package that depends on rJava and all advices were telling me to fix Java installation. But the solution was to use install option that simply forgets about i386 architecture. (also works with drat library and packages not from CRAN)
This may be due to a conflict between RStudio and Java versions. If you have installed 64 bit java and RStudio is running in 32 bit mode, you may experience problems like this. As a solution, you can change the 32-64 bit selection in the Tools-> Global Options-> General section in RStudio.
You can find detailed information here.
In my case installing proper version of Java solved my problem.
I installed 64x bit java, cause I use 64x bit R version.
I solved it by following these steps
setting my environment Sys.setenv(JAVA_HOME='C:\\Program Files (x86)\\Java\\jre6')
Manually installing rJava package from install package (even this should work:
install.packages('rJava', .libPaths()[1], 'http://www.rforge.net/'))
library(rJava)
I solved this problem as follows. I've been trying for 2 days.
Windows 7 users do not write ... \ bin \ x64 in environment variables.
Instead, define the path as follows.
JAVA_HOME "C: \ Program Files \ Java \ jre1.8.0_251"
R_HOME C: \ Program Files \ R \ R-3.5.3
In RStudio type .LibPaths()
This will give you an path in you windows system where your library’s are located
Go there and delete rJava. If it is being used by applications of Java, kill all Java programs in the Task Manager.
Go to computer and properties, click on change environment variables
Edit JAVA_HOME and all Java related paths to the path where your newest installation of Java is located and save.
I try to run my R script in Java, thus I installed JRI. and run the example, I am using Eclipse on 64 bits windows 7. part of the example code is as follows:
public static void main(String[] args) {
System.out.println("Creating Rengine (with arguments)");
Rengine re=new Rengine(args, false, null);
System.out.println("Rengine created, waiting for R");
if (!re.waitForR()) {
System.out.println("Cannot load R");
return;
}
However, everytime I run it. it teminated after print out "Creating Rengine (with arguments)" never successfully print out "Rengine created, waiting for R"
I do not know what is right argument to input, I have tried to add "--no-save" under the Program arguments of eclipse run configuration, but still does not help.
any suggestions? Many thanks
Ref: http://www.rforge.net/JRI/
R_HOME must be set correctly
(Windows): The directory containing
R.dll must be in your PATH
(Mac): Well, it's a Mac, so it just
works ;).
(unix): R must be compiled using
--enable-R-shlib and the directory containing libR.so must be in
LD_LIBRARY_PATH. Also libjvm.so and
other dependent Java libraries must
be on LD_LIBRARY_PATH.
JRI library must be in the current
directory or any directory listed in
java.library.path.
Alternatively you can specify its
path with -Djava.library.path=
when starting the JVM. When you use
the latter, make sure you check
java.library.path property first such
that you won't break your Java.
Depending on your system, the R
verison and other features you want
to use, you may have to set
additional settings such as
R_SHARE_DIR, R_INCLUDE_DIR and
R_DOC_DIR.
My own notes:
Installing R on Mac:
Ref: http://cran.r-project.org/mirrors.html
Ref: http://cran.r-project.org/bin/macosx/RMacOSX-FAQ.html
Downloaded MacOSX binary R-2.13.0.pkg from http://cran.csiro.au/
Installing Java Interface for R (JIR) on Mac OS X
Ref: http://www.rforge.net/JRI/
JIR is now a part of rJava.
> install.packages("rJava")
--- Please select a CRAN mirror for use in this session ---
trying URL 'http://cran.csiro.au/bin/macosx/leopard/contrib/2.13/rJava_0.8-8.tgz'
Content type 'application/x-gzip' length 769006 bytes (750 Kb)
opened URL
==================================================
downloaded 750 Kb
The downloaded packages are in
/var/folders/ZZ/ZZ7tAIJsFU8FDfPPp7H53++++TM/-Tmp-//RtmpCHz9Mh/dow
> library(rJava)
> .jinit()
> s <- .jnew("java/lang/String", "Hello World!")
> print(s)
[1] "Java-Object{Hello World!}"
Running JRI example Java with Eclipse on Mac OS X
Copied the rJava/jri/examples/rtest.java to Eclipse JRI/src/.
Copied the JRI.jar from the jri directory to the JRI/lib/ and added it to the build path.
The rtest.java compiles but it did not run as a Java application.
Apparently, it needs to be run by: ./run rtest.
After examining the "run" shell script which comes with the rJava package (inside ./jri/), I have set up these in the Eclipse run configuration:
Environnment:
R_HOME = /Library/Frameworks/R.framework/Resources
PATH=/Library/Frameworks/R.framework/Resources/bin/
In addition, the example run shell script sets up the following Environment vars:
R_INCLUDE_DIR=Library/Frameworks/R.framework/Resources/include
R_SHARE_DIR=Library/Frameworks/R.framework/Resources/share
R_DOC_DIR=Library/Frameworks/R.framework/Resources/doce
JRI_LID_PATH=Library/Frameworks/R.framework/Resources/lib:/Library/Frameworks/R.framework/Resources/bin
VM argument:
-Djava.library.path=/Library/Frameworks/R.framework/Resources/library/rJava/jri/
JRI.jar is now referenced in the build path, which is:
/Library/Frameworks/R.framework/Resources/library/rJava/jri/JRI.jar.
This automatically appears under the -cp tab in the run configuration.
Also, the run configuration requires a program argument: --save, --no-save or --vanilla.
Chances are it's not finding jri.dll or R.dll. If you see nothing, not even an exception, the JVM is crashing. Look for files like hs_pid* which should tell you which library is the culprit.
I have found this question in my own struggles with R on Windows, although on Linux it just worked.
I too found I was getting "Creating Rengine (with arguments)" but nothing further.
It was finding jri.dll and R.dll, which I was able to prove:
jri.dll - deleted it from the current directory, which generated the error:
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: no jri in java.library.path
(on copying it back, make sure to take the right 32 or 64 bit version to avoid "Can't load IA 32-bit .dll on a AMD 64-bit platform" type errors)
R.dll lives under the installation directory C:\Program Files\R\R-2.15.0\bin\x64
If the PATH is set incorrectly in the run.bat file (which it was) then you get the slightly different error
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: [CURRENT DIR]\jri.dll: Can't find dependent libraries
With those two things set correctly (and no hs_pid* files being generated) I found the problem to be the lack of R_HOME in run.bat. Adding
set R_HOME=C:\Program Files\R\R-2.15.0\
fixed it, and now it all seems to work for me. I did not need to add --save, --no-save or --vanilla to the script. Also, it had 'runtest' hardcoded, so ./run.bat runtest2 will not DWYM.
Short answer: The Windows run.bat script was broken (whereas the Linux 'run' script was correct out of the box).
I got the same problem while working with rJava, Windows 7 64 bit.
And here is the solution.
Added -Djava.library.path="${env_var:PATH}" in eclipse -> Project -> Run As -> Run Configuration -> Arguments.
And make sure System.getProperty("java.library.path") is pointing to jri.dll
I spent lot of time on this issue, so feel free to ask any questions ;)
The below error can be due to two paths not set, one is r.dll not found or/and jri.dll not found. Make sure system path includes for 32 bit systems
%R_HOME%\bin;%R_HOME%\bin\i386;%R_HOME%\library\rJava\jri\i386
Also make sure install.packages("rJava") plugin is installed from R console
Cannot find JRI native library!
Please make sure that the JRI native library is in a directory listed in java.library.path.
java.lang.UnsatisfiedLinkError: no jri in java.library.path
at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1886)
at java.lang.Runtime.loadLibrary0(Runtime.java:849)
at java.lang.System.loadLibrary(System.java:1088)
at org.rosuda.JRI.Rengine.<clinit>(Rengine.java:19)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:274)
at org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(CallSiteArray.java:65)
at org.codehaus.groovy.runtime.callsite.CallSiteArray$1.run(CallSiteArray.java:62)
at java.security.AccessController.doPrivileged(Native Method)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallStaticSite(CallSiteArray.java:62)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.createCallSite(CallSiteArray.java:159)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:45)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:108)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:112)
at com.acumetric.crux.analysis.StatisticCalculator.<init>(StatisticCalculator.groovy:15)