I'm trying to build an R package which is calling some C subroutines via .Call.
All of the functions are working fine if I manually do R CMD SHLIB and then dyn.load the .dll files.
Now, I'm building the package with R CMD build.
I put all the C code in the src folder, together with the .h files for some libraries I'm adding. When I run R CMD build NAMEPACKAGE everything seems to be fine, but then when I run R CMD check NAMEPACKAGE I get the following errors:
*** arch - i386
Error in library.dynam(lib, package, package.lib) :
DLL 'NAMEFUNC' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
*** arch - x64
Error in library.dynam(lib, package, package.lib) :
DLL 'NAMEFUNC' not found: maybe not installed for this architecture?
Error: loading failed
Execution halted
ERROR: loading failed for 'i386', 'x64'
I was trying to get some information on the internet, I have the feeling that I should write a Makevars file, but honestly I spent a lot of time on the Writing R extensions tutorial (1.2.1) and I'm really struggling to understand what is it exactly that I need to do.
Could someone please beifly explain to me how to solve the problem? Consider I would like to submit my package to CRAN. Thanks.
I just found out what the problem was! It was (as usual) a fairly silly thing, I didn't know that even if you call a certain function with a certain name, the associated dll is automatically called with the name of the package and not of the function itself, like it happens instead when you just create your dll through R CMD SHLIB.
Therefore, in the NAMESPACE I had to add useDynLib(NAMEOFPACKAGE) instead of useDynLib(NAMEOFFUNCTION).
Related
Let me preface this, I am very new to linux and to working on a non-IDE based setup.
I am trying to debug a very simple C program using vs code version 1.55
I unloaded all modules beforehand, so vs code can load appropriate default gcc & gdb versions (which it did, GCC 8.2)
I am following the VS code getting started documentation for setting up and everything seems very straight forward until I try to debug.
I use the default settings as instructed, the file builds successfully but then I get the below
/usr/bin/gdb: symbol lookup error: /usr/bin/gdb: undefined symbol: PyUnicodeUCS4_FromEncodedObject
please note that I cannot rebuild python with ucs4 enabled as suggested in another thread as I have no root access. however I can change VS code version to an earlier one if this will help.
Thanks.
I think this issue is specific to my environment but I will post the answer anyway as it may face someone else.
So this for me was 2 separate issues:
First gdb doesn't start and second vs code can't start gdb.
To check if this is the case try to launch gdb from terminal (not vs code) by typing gdb in the terminal (after loading gdb if needed), I was receiving the error above
Solution to this part is this as T0maas thankfully suggested above
Steps for linux newbies:
ldd gdb (or /usr/bin/gdb) (with vs_code loaded)
from step one get the python library path
unload all modules
load gdb
LD_PRELOAD=<python path from 1>
bash -c "export LD_PRELOAD"
load vs_code
load gdb
After the above steps writing gdb in the terminal should start gdb
Part 2:
The rest of the problem was when I tried to launch debugging session through the GUI of vs_code (still produced the same error)
In the terminal (after loading gdb) type whereis gdb
For me this produced multiple directories the first of which was /usr/bin/gdb (this is the default used in vs_code launch.json)
Changing that directory in the launch.json file to a different one of the other directories solved the second part of the problem for me.
I am trying to modify an R package that works with C and Fortran code, so in order to test my modifications im trying to compile this C code in R. I have never worked before with C so I am following the steps described at this website: http://mcglinn.web.unc.edu/blog/linking-c-with-r-in-windows/
I have completed all the steps: Downloaded Rtools, modified the PATH, created the C file with some functions and compiled it. The .dll file has been correctly generated (seems so). But when I try to load this code into R using dyn.load I get the following error:
dyn.load("sequence_examples.dll")
Error in inDL(x, as.logical(local), as.logical(now), ...) :
unable to load shared object 'C:/Users/alvaromc317/ZZ_ALVARO/sequence_examples.dll':
LoadLibrary failure: %1 is not a valid Win32 application.
I am not sure what is going wrong. My system works with an x64 architecture, so I installed R and Rtools x64 versions.
I am a newbie working with Cygwin and CUnit. I have to develop some Unit Tests using CUnit and Netbeans and I have followed the next tutorial:
https://netbeans.org/kb/docs/cnd/c-unit-test.html?print=yes#project
At the end, when I was trying to run the first example test I got stocked by an error:
0 [main] make 4380 C:\cygwin\bin\make.exe: *** fatal error - error while loading shared libraries: /cygdrive/C/Program Files/NetBeans 8.0.2/ide/bin/nativeexecution/Windows-x86_64/unbuffer.dll: cannot open shared object file: Exec format error
448 [main] make 4380 open_stackdumpfile: Dumping stack trace to make.exe.stackdump
I don't know if this has relation to the Cygwin version I have, I have a computer running Windows 7 Enterprise 64bits edition. I have configured my C project to use Cygwin 64bits edition...
Could you please share any idea about how I can solve this?
Thanks!
I had a similar issue, but in my case I was trying to run CppUnit tests in Netbeans. I was using make provided by MSYS2 and it was failing to load unbuffer.dll, but error was "No such file or directory". I switched the make from MSYS2 for the one found in MSYS and the error went away. You could try this as a workaround.
I found sole here:
https://bz.apache.org/netbeans/attachment.cgi?id=164026&action=edit
Need download new version of unbuffer.dll.
Yar
I'm trying to statically link glib into my C program. I'm not sure what's the best way to do this. I downloaded the code and put it in a subdirectory called glib-2.36.4. I added "-Iglib-2.36.4" when using gcc. The glib.h is in the glib-2.36.4/glib directory and in that file there are references to other header files under the glib directory (such as #include ).
I'm not sure why that is since both glib.h and these other header files are at the same level (in glib subdirectory). I got a compile error due to galloca.h not being found (even though it's there). So I copied glib.h up one level and those errors went away. I then got an error about a missing glibconfig.h. I copied that from my usr directory and that error went away. I compiled my project and now I'm getting an error about undefined reference to g_ptr_array_new. I guess this must be because I haven't actually compiled glib. I had tried to build glib, but when I typed "./configure", but I got this message:
checking if arpa/nameser_compat.h is needed... configure: error: could not compile test program either way
I did install glib using yum, but I really want this code to run even if glib is not installed on a machine.
You need to install both glib and glib-dev via yum, compile using ./configure, (take a look in the ./configure script to see if there are any flags you need to supply or defines you need to produce the static build), without moving any files about, and then you need to compile your code using -i path/to/glib/includes and link with -L path/to/built/static/library
I have a problem with the libstdc++.so.6 library when I execute a program in MATLAB. The code works fine on my laptop and my desktop, which is why I'm sure the problem is a library or linking compatibility issue:
/home/arturo/Virality/viral_cluster_ml/Viral_features/code/segment_pedro/segment: error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
I've google some answers on how to fix the library, and some say that I should remove the library to later re-install the correct version:
error while loading shared libraries: libstdc++.so.6: wrong ELF class: ELFCLASS64
The problem is that I can't afford the luxury to delete a library, because I am ssh'ing to a cluster at the lab I'm working in. I really wouldn't want to mess up any programs that are running at the cluster, so isn't there another way of fixing this problem? I'm hoping a solution similar to:
sudo apt-get install libstd++6
that doesn't require me to delete or modify any files, but rather to install them.
Or maybe the error is that I'm not linking the library correctly?
The file does exist, as when I use
locate libstd++.so.6
the computer finds it at these directories:
/usr/lib64/libstdc++.so.6
/usr/lib64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2012b/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/local/MATLAB/R2012b/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6
/usr/local/MATLAB/R2013a_DCS/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/bin/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6
/usr/local/Matlab_R2012a/sys/os/glnxa64/libstdc++.so.6.0.13
/usr/local/Matlab_R2012a/toolbox/sldv/sldv/polyspace-dvo/lib/x86-linux/libstdc++.so.6
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.13-gdb.pyo
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.py
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyc
/usr/share/gdb/auto-load/usr/lib64/libstdc++.so.6.0.13-gdb.pyo
I've also tried setting the path to the the file before running MATLAB, without anyluck:
LD_LIBRARY_PATH=/usr/lib64:/home/arturo/Virality/viral_cluster_ml/Viral_features/code/scene_sun ./matlab
Similar link and problem:
http://www.linuxquestions.org/questions/linux-newbie-8/apt-get-messed-up-812346/
Problem was solved by recompiling a subfolder of the code on the cluster.