I am writing a C code that I will use in R. To do matrix operations in C, I added "gsl_matrix" library. When I compile using R CMD SHLIB it compiles without problem. However when I open R and try to write dyn.load("file.so"), I receive an error message:
unable to load shared object file.so
undefined symbol: gsl_matrix_alloc
Where is my mistake?
I suspect this has to do with your shared library that is not properly linked to GSL libs, as discussed on R-devel, or the manual on Writing R Extensions, where it is suggested to use a Makevars file (with something like PKG_LIBS=-L/usr/lib -lgsl). Otherwise, following the example in help(SHLIB), you may want to try:
$ R CMD SHLIB file.c -lgsl -lgslcblas
There is a simple tutorial, R Call GSL, which shows basic setup for calling GSL functions.
I am able to reproduce the toy example, that I renamed nperms.{c,r} as follows (on a Mac, whence the use of a -dynamiclib switch in place of -shared):
~/scratch $ gcc -c nperms.c
~/scratch $ file nperms.o
nperms.o: Mach-O 64-bit object x86_64
~/scratch $ gcc -dynamiclib -lgsl -lgslcblas -o libnperms.dylib -dylib nperms.o
~/scratch $ ls *nperm*
libnperms.dylib nperms.c nperms.o
~/scratch $ file libnperms.dylib
libnperms.dylib: Mach-O 64-bit dynamically linked shared library x86_64
Everything works fine when dyn.load'ing libnperms.dylib in R. However, using shared library generated from R CMD SHLIB without further argument
~/scratch $ R CMD SHLIB nperms.c
gcc -arch x86_64 -std=gnu99 -dynamiclib -Wl,-headerpad_max_install_names -undefined dynamic_lookup -single_module -multiply_defined suppress -L/usr/local/lib -o nperms.so nperms.o -F/Library/Frameworks/R.framework/.. -framework R -Wl,-framework -Wl,CoreFoundation
~/scratch $ ls *nperm*
libnperms.dylib nperms.c nperms.o nperms.r nperms.so
~/scratch $ file nperms.so
nperms.so: Mach-O 64-bit dynamically linked shared library x86_64
raises the following error (sorry for the French locale)
> dyn.load("nperms.so")
Erreur dans dyn.load("nperms.so") :
impossible de charger l'objet partag'e '/Users/chl/scratch/nperms.so':
dlopen(/Users/chl/scratch/nperms.so, 6): Symbol not found: _gsl_permutation_alloc
Referenced from: /Users/chl/scratch/nperms.so
Expected in: flat namespace
in /Users/chl/scratch/nperms.so
I have not a direct answer to your question but did you try http://cran.r-project.org/web/packages/RcppGSL/index.html or http://cran.r-project.org/web/packages/RcppArmadillo/index.html?
Related
I'm trying to make a repository collecting all the examples, tutorials and instructions I could find on the internet for C mathematical and algebra libraries (BLAS, CBLAS, LAPACK, CLAPACK, LAPACKE, ATLAS, openblas, GSL...). but it seems that I just can't get the compiled BLAS .a files working on mac OS X.
So far I have been able to compile BLAS and use it on ubuntu:
BLAS source code from netlib website downloaded and compiled (rename blas_LINUX.a to libblas.a)
Then I can compile the C file on ubuntu using the command below:
gcc foo.c path/to/libblas.a
On my mac OS X (EL Capitan), I can compile BLAS (changing LINUX in the make.inc to DARWIN), but when I try to compile a C code using the command above I get errors like below:
Undefined symbols for architecture x86_64:
"_ddot_", referenced from:
_main in foo-3a35db.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
("ddot" part differs for different functions)
possibilities:
Maybe I'm not compiling the library correctly on mac and there are some differences I'm not aware of
The builtin Accelerate framework of mac OS X is messing up with the compiling process
P.S. Guys I know BLAS/LAPACK is already built into the mac OS X Accelerate framework and I can easily compile using the command gcc foo.c -lblas or gcc foo.c -framework Accelerate but I want to use the compiled .a from netlib. I want to know why it works properly on ubuntu but not mac OS X?
P.S.2. Please notice that I can compile the source code successfully without any errors on mac OS X. I just can use it!
Example code: source
#include <stdio.h>
#include <stdlib.h>
double ddot_(const int *N, const double *a, const int *inca, const double *b, const int *incb);
int main(int argc, char **argv) {
double *a = (double *)malloc(3 * sizeof(double));
a[0] = 1.0;
a[1] = 2.0;
a[2] = 3.0;
// on the stack
double b[3] = {4.0, 5.0, 6.0};
int N = 3, one = 1; // one really doesn't look good in C
double dot_product = ddot_(&N, a, &one, b, &one);
printf(" The dot product is: %f \n", dot_product);
return 0;
}
(edit1) solution:
open make.inc
change the line OPTS = -O3 to OPTS = -O3 -pipe -c and make.
(edit2): better solution:
since I asked this question I have realised that I have been doing everything wrong. Netlib BLAS is actually a collection of fortran routines/subroutines/functions. and the Makefile in the source code just gives us a static library libblas.a which is a collection of all .o object files compiled with gfortran. when we want to compile a C code which want to call one of those routines, we also need to link to the gfortran library libgfortran.* so if you have gcc installed (brew install gcc). look for libgfrotran* (sudo find / -name "libgfortrn.*") and then link your gcc to this folder too. to make it easy I put a Makefile here:
all:
gcc -c foo.c
gcc -o bar.out foo.o -L path/to/libgfortran.*/ -lgfortran -L path/to/libblas.a -lblas
or alternatively compile the code directly with gfortran:
all:
gcc -c foo.c
gfortran -o bar.out foo.o -L path/to/libblas.a -lblas
or simply compile with:
gcc foo.c bar.out -L path/to/libblas.a -lblas -L path/to/libgfortran.*/ -lgfortran
the wonder is how/why the former solution actually worked and why on ubuntu you don't have to link to -lgfortran!
It seems you compiled BLAS library from Netlib with compiler options that changed the mangling scheme of Fortran routines.
By default, Netlib's make.inc uses gfortran to compile BLAS:
$ grep FORTRAN make.inc
# Modify the FORTRAN and OPTS definitions to refer to the
FORTRAN = gfortran
It is compiled without any flags:
gfortran -O3 -pipe -c ddot.f -o ddot.o
and you get the ddot() routine:
$ grep -i ddot ddot.o libblas.a
Binary file ddot.o matches
Binary file libblas.a matches
And you can find it with the command line tools:
$ nm ddot.o libblas.a | grep -i ddot
ddot.o:
0000000000000000 T _ddot_
libblas.a(ddot.o):
0000000000000000 T _ddot_
Your example compiles with the library:
cc ex.c libblas.a
or with the ddot.o file:
cc -pipe ex.c ddot.o
I cannot reproduce your problem. You should use the nm and grep commands to find out what happened to the name of the ddot() routine.
PS. Your code has extra semicolon ; after the end of definition of main().
I am a Unix/Linux newbie who is trying to run a shell script written by a person who left no documentation and has since demised. This script contains line:
./search $opt1 $arg1 < $poly 2>&1 | tee $output
Which is trying to get the file $poly and call program ./search and divert the output to $output.
When I get to this line, I am given message: ./search: cannot execute binary file: Exec format error
search is a C program called from the script and is in the same folder as various other C programs to do with this project. Script and C programs were developed and originally executed on a Unix/Linux box which is no longer available, so I have been asked to try to resurrect this project but under Windows using gcc in NetBeans and cygwin.
The message : ./search: cannot execute binary file: Exec format error is most likely to do with the fact there is no executable file for search. When I try to build the C programs I get the following output:
C:\cygwin64\bin\make.exe -f Makefile
gcc -ansi -g -c cbuild.c
gcc -ansi -g -c complex.c
gcc -ansi -g -c mylib.c
gcc -ansi -g -c poly.c
gcc -ansi -g -c real.c
gcc -ansi -g -c zero.c
gcc -lgmp -lm -lrt -o cbuild cbuild.o complex.o mylib.o poly.o real.o zero.o
real.o: In function `rabs':
/cygdrive/c/../progs/real.c:9: undefined reference to `__imp___gmpf_abs'
/cygdrive/c/../progs/real.c:9:(.text+0x1e): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `__imp___gmpf_abs'
real.o: In function `radd':
I assume that R_X86_64_PC32 refers to the environment I am using. I am using a 64 bit version of Netbeans with gcc 5.4.0 in a 64 bit version of cygwin on Windows 10.
Can anyone advise what I must to to resolve this so that I can build the C programs?
The problem is this:
gcc -lgmp -lm -lrt -o cbuild cbuild.o complex.o mylib.o poly.o real.o zero.o
By default, the linker will link libraries and objects in the order specified on the command line, and, when linking a library, will only include symbols needed by things before it on the command line. Since -lgmp is first, there are (as yet) no outstanding symbols (except main), so nothing is included from the library. When later objects need the symbols from it, they won't see them.
Change the order to
gcc -o cbuild cbuild.o complex.o mylib.o poly.o real.o zero.o -lgmp -lm -lrt
and it should work. Alternately, use the -Wl,--as_needed linker option to get the linker to remember earlier libraries and relink them if more symbols from them are referenced by later object files (requires a recent version of the GNU linker -- I have no idea if it works with cygwin).
This kind of misordering is usually a symptom of a broken Makefile. The normal Makefile structure has a bunch of variables that are set to control the default rules that know how to compile source files and link object files. The two variables relevant for linking are LDFLAGS and LDLIBS, and the difference is that LDFLAGS comes before all the object files on the command line and LDLIBS comes after all the object files.
So in order to make things work, you need to ensure that all of the -l options and other libraries are in LDLIBS:
LDLIBS = -lgmp -lrt -lm
and NOT in LDFLAGS
I'm switching from gcc to Intel ifort and icc.
The Fortran code is mostly legacy, likewise the the rest of the system.
The main program is written in C. It handles the I/O and passes everything to a Fortran subroutine.
For now I compile the Fortran part with:
cd fortran
ifort -I../inc -debug full -c *.[fF]
cd ..
For C and linking I tried:
icc -ansi -static -debug full -Wall -o testout \
-I./inc -L./lib\
main.c \
fortran/*.o \
-lifcore -limf -lm\
this gives me:
ld: cannot find -lm
ld: cannot find -lm
ld: cannot find -lc
ld: cannot find -ldl
ld: cannot find -lc
This is mostly copied from the former bash script to compile with gcc.
The -static flag will link all the libraries statically. In that case you need to have a static version (the .a files) of every library. For example, using -lm will search for libm.a. Those libraries are not installed by default, but may be in the -dev or -devel packages of your distribution.
If you only want to link statically the Intel libraries, then you should use -static-intel.
A good trick to avoid static linking is to:
1) Dynamically link your program with -static-intel and -Wl,-rpath=./lib
2) Use ldd to find which libraries your program needs
3) Create a directory lib where you copy all the required dynamic libraries
4) Instead of distributing your code as a single static binary you can disrtibute it as a binary + the lib directory (assuming the licenses of the libraries permit it).
Finally, if you need to try more things, I have succeeded to link an Intel Fortran file with gcc using this command:
$ gcc fortran_file.o c_main_file.o -lifcore -lirc -lcomposerxe_gen_helpers_core_2.3
hope this helps...
I have got the object-file from source code using MinGW.
But on linking:
ld -o test.exe test.o
I get errors, for example the following:
undefined reference to printf
First, why are you using ld directly?
The following is an excerpt from the "GCC and Make" tutorial found at http://www3.ntu.edu.sg/home/ehchua/programming/cpp/gcc_make.html.
Compile and Link Separately
The above command compile the source file into object file and link with other object files (system library) into executable in one step. You may separate compile and link in two steps as follows:
// Compile-only with -c option
> g++ -c -Wall -g Hello.cpp
// Link object file(s) into an executable
> g++ -g -o Hello.exe Hello.o
Note g++ (you can substitute gcc if you are using C and not C++) is used both for compiling and linking. ld is not used at all.
The benefit of using g++ or gcc to link is that it will link with default libraries, such as the one you need to link with for printf, automatically.
To link with other libraries, you specify the library name with the -l parameter, as in -lmylib.
We can view commands ran by compiler via command
c99 -v test.o
We'll get some text. All after string which contains "COLLECT_CGG_OPTIONS" will be arguments of ld.
But size of executable file is much more then size of file got by previous way.
I'm getting this error when trying to compile:
error: undefined reference to `sinf'
I have included math.h, and verified that it is defined in there:
#include <math.h>
However, I get an error while trying to link to the math library:
arm-none-eabi-ld -L/usr/lib -lm --gc-sections -T ../standalone.ld -o "main.elf" ./main.o ./startup_gcc.o
error: cannot find -lm
However, the library is obviously there:
Kens-MacBook-Pro:lib Ken$ pwd
/usr/lib
Kens-MacBook-Pro:lib Ken$ ls | grep libm
libm.dylib
libmecab.1.0.0.dylib
libmecab.dylib
libmecabra.dylib
libmenu.5.4.dylib
libmenu.dylib
libmx.A.dylib
libmx.dylib
Kens-MacBook-Pro:lib Ken$
What am I doing wrong? I'm using Eclipse.
Judging by your arm-none-eabi-ld command, I'm assuming you're cross compiling. You need to install some sort of math library into the toolchain for whatever your platform is.
The ls output you posted contains a list of libraries available for your host, not your target. On my machine, the libraries for my ARM cross-compiler resides in /opt/local/arm-none-eabi/lib/ for example.
danieltang ~$ ls /opt/local/arm-none-eabi/lib/
crt0.o ldscripts libm.a libssp_nonshared.a libstdc++.a-gdb.py libsupc++.la
elf2flt.ld libc.a libssp.a libssp_nonshared.la libstdc++.la thumb
fpu libg.a libssp.la libstdc++.a libsupc++.a