Dear R-devel, I am trying to use Fortran DGESV subroutine into C. Here it is the relevant part of the C file I am currently writing #include<stdio.h> #include<R.h> #include<Rmath.h> #include<math.h> void F77_NAME(DGESV)( int*, int*, double*, int*, int*, double*, int*, int*); void solve( int *p, double *A, double *Ainv) { ... F77_CALL(DGESV)(p, p, Ain, p, ipiv, Bin, p, &info); } In order to create the ".so" file to load in R I downloaded the dgesv.f file as well as the dependencies (dgetf2.f dgetrf.f dgetrs.f dlaswp.f). As I was used to I ran in a terminal R CMD COMPILE *.f R CMD SHLIB MY_C_FILE.c *.o to get the MY_C_FILE.so file. However, when I try to load it in a R session I get the following error message "undefined symbol: DGESV_". Similar errors are occurring with some other (old) C files that I was used to use a couple of years ago. In this connection I have to say that those file were working under an older linux version (I guess ubuntu 12.04 LTS rather than the current one which is 14.04 LTS). Best Regards, N. Lunardon -- View this message in context: http://r.789695.n4.nabble.com/F77-CALL-NAME-problem-tp4705076.html Sent from the R devel mailing list archive at Nabble.com.
I was not able to find why my old way to do things did not work. However, I "discovered" that dgesv is also in the header Lapack.h. So I just dropped form the C code the declarations F77_NAME/CALL and used directly function dgesv_ as declared in Lapack.h. Of course I had to compile with the -llapack flag. -- View this message in context: http://r.789695.n4.nabble.com/F77-CALL-NAME-problem-tp4705076p4705096.html Sent from the R devel mailing list archive at Nabble.com.
On Wed, Mar 25, 2015 at 4:44 AM, bstr <nicola.lunardon at hotmail.it> wrote:> Dear R-devel, > > I am trying to use Fortran DGESV subroutine into C. Here it is the relevant > part of the C file I am currently writing > > #include<stdio.h> > #include<R.h> > #include<Rmath.h> > #include<math.h> > > void F77_NAME(DGESV)( int*, int*, double*, int*, int*, double*, int*, int*); > > void solve( int *p, double *A, double *Ainv) > { > ... > F77_CALL(DGESV)(p, p, Ain, p, ipiv, Bin, p, &info); > }Try lower case. void F77_NAME(dgesv)( int*, int*, double*, int*, int*, double*, int*, int*); void solve( int *p, double *A, double *Ainv) { ... F77_CALL(dgesv)(p, p, Ain, p, ipiv, Bin, p, &info); } The lapack.so file has a name "dgesv_" in it, not DGESV_.> > In order to create the ".so" file to load in R I downloaded the dgesv.f file > as well as the dependencies (dgetf2.f dgetrf.f dgetrs.f dlaswp.f). As I was > used to I ran in a terminal > > R CMD COMPILE *.f > R CMD SHLIB MY_C_FILE.c *.o > > to get the MY_C_FILE.so file. However, when I try to load it in a R session > I get the following error message "undefined symbol: DGESV_". Similar errors > are occurring with some other (old) C files that I was used to use a couple > of years ago. In this connection I have to say that those file were working > under an older linux version (I guess ubuntu 12.04 LTS rather than the > current one which is 14.04 LTS). > > Best Regards, > > N. Lunardon-- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown
You said you changed F77_NAME(DGESV) to dgesv_ to make it work and inferred that F77_NAME was the the problem. I suspect that things got better because you changed the capitalization and that F77_NAME(dgesv) would have worked as well. Adding #include <R_ext/Lapack.h> to your code would declare these things as well (and declare them properly, with the 'const' declarations in the appropriate places). Bill Dunlap TIBCO Software wdunlap tibco.com On Wed, Mar 25, 2015 at 9:36 AM, bstr <nicola.lunardon at hotmail.it> wrote:> I was not able to find why my old way to do things did not work. However, I > "discovered" that dgesv is also in the header Lapack.h. So I just dropped > form the C code the declarations F77_NAME/CALL and used directly function > dgesv_ as declared in Lapack.h. Of course I had to compile with the > -llapack > flag. > > > > -- > View this message in context: > http://r.789695.n4.nabble.com/F77-CALL-NAME-problem-tp4705076p4705096.html > Sent from the R devel mailing list archive at Nabble.com. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >[[alternative HTML version deleted]]
Thank you John and William for the replies! @John: I downloaded the Fortran files from http://www.netlib.org/lapack/double/ <http://www.netlib.org/lapack/double/> (the link "dgesv.f plus dependencies"). In file dgesv.f the subroutine is declared as SUBROUTINE DGESV( N, NRHS, A, LDA, IPIV, B, LDB, INFO ) with capital letters. @William: after looking for a while for a solution I discovered that R had "embedded" all the things I needed, so I just got rid of F77_NAME/CALL in my C code and simply called dgesv_ as declared in Lapack.h (adding as you suggested #include <R_ext/Lapack.h> in the preamble). So I did not changed the previous declarations of DGESV in my C file to lower case. On the one hand, it seemed (and seems) to me quite odd that my old code did not work and I would like to know why, even if it not a priority anymore. On the other hand, I am happy to have found a new, and, I suppose, more "R-package" oriented way, to use Fortran's linear algebra routines in my C code. N. Lunardon -- View this message in context: http://r.789695.n4.nabble.com/F77-CALL-NAME-problem-tp4705076p4705128.html Sent from the R devel mailing list archive at Nabble.com.
Apparently Analagous Threads
- Computing time when calling C functions - why does an extra function call induce such an overhead?
- Lapack / dgesvx function declaration
- F77_CALL, F77_NAME definition
- Lapack, determinant, multivariate normal density, solution to linear system, C language
- Problem with shared library and lapack under windows