I tried to find the definition of a function cblas_Xaxpy in Kaldi, so I was directed by GOTO Definition to the final place cblas-wrappers.h, where I found
inline void cblas_Xaxpy(const int N, const float alpha, const float *X,
const int incX, float *Y, const int incY) {
cblas_saxpy(N, alpha, X, incX, Y, incY);
}
Apparently the key is cblas_saxpy, first I tried to direct to the source file of this header file, but I did not find any. So I have tried search the whole directory and the parent directory concerning the project and I could not find any file containing the real definition of cblas_saxpy. But this is the original code and I ran it smoothly.
Then I am confused: if this is the correct version, then there should be some place to define the function cblas_saxpy's implementation, but where is it ?
cblas_saxpy() is defined in the LAPACK library. (As this is a C library, the source code does not need to be present to compile software against the library.) The definition of cblas_saxpy in that library is a wrapper around some extremely old Fortran code.
Related
I have a C library that I want to use from within Octave. Following the tutorial, it seems straight forward: wrap the functions in C++ then mkoctfile them. The problem is: what if I want to have multiple functions definitions (wrappers) in a single source file?
In the mentioned tutorial it is stated
It should be noted that it is perfectly acceptable to have more than one DEFUN_DLD function in a source file. However, there must either be a symbolic link to the oct-file for each of the functions defined in the source code with the DEFUN_DLD macro or the autoload (Function Files) function should be used.
Then in the provided link:
Once Octave finds a file with a name that matches (the called function), the contents of the file are read. If it defines a single function, it is compiled and executed. See Script Files, for more information about how you can define more than one function in a single file.
In this second link, there is no info as to how to load a .oct file with multiple functions in it or how to generate multiple .oct files from a single source file. From what I've understood, the later is the correct approach. How can I do that?
The point of the second link is that you don't load a .oct file with multiple functions in it - at least not from octave's perspective. That's what the symlinks are for - you have symbols A, B, and C in there? Make A.oct, B.oct, and C.oct symbolic links that point at that file and you can use them as if each contained only the symbol you care about.
If you have multiple function definitions in a single oct file, you use autoload(). So if you have foo.oct which has functions foo and bar, then you do:
autoload ("bar", "path-to-foo.oct");
I'll start by clarifying the second quote-window in your question. This is not referring specifically to .oct defined functions. What this is implying is the difference between a canonical m-file defined function, and 'on-the-spot' functions defined directly in the console or as part of a script.
As for the first quote-window, when it comes to functions that are defined in .oct files, the situation is different. What it's saying is that you can create an .oct file that defines many functions, but in order to call these functions, there needs to be a file by the same name in your path. So if an .oct file defines functions "foo" and "bar", you need to have one copy of the .oct file called "foo.oct", and another (or, more realistically, as symbolic link to the original) renamed as "bar.oct".
Similarly, you can also define a "foo.m" and "bar.m" file in your workspace, which only contains the documentation for those functions, such that if you then do "help foo" or "help bar" you get the intended documentation out.
Alternatively, you can use autoload, as carandraug suggested.
Another possibility to generate a C to Octave interface is using SWIG which can generate a single .oct file with all your functions. Refer to here when using pointers and arrays.
Here is an example:
header
/* File: example.h */
int fact(int n);
int fact2(int n1, int n2);
void add(int *x, int *y, int *r);
source
/* File: example.c */
#include "example.h"
int fact(int n) {
if (n < 0){ /* This should probably return an error, but this is simpler */
return 0;
}
if (n == 0) {
return 1;
}
else {
/* testing for overflow would be a good idea here */
return n * fact(n-1);
}
}
int fact2(int n1, int n2) {
return fact(n1)*fact(n2);
}
void add(int *x, int *y, int *r) {
*r = *x + *y;
}
interface
/* File example.i */
%module swigexample
%include "cpointer.i"
%{
#include "example.h"
%}
%pointer_functions(int, intp)
%include "example.h"
compile
swig -octave -o swigexample.cpp example.i
mkoctfile -I. -I/usr/include/octave-4.2.2/ -Iswiglib swigexample.cpp example.c
test
% File test.m
swigexample;
fact(5)
fact2(4,4)
% ==============
a = new_intp();
intp_assign(a, 37);
b = new_intp();
intp_assign(b, 22);
c = new_intp();
add(a,b,c);
r = intp_value(c);
delete_intp(a);
delete_intp(b);
delete_intp(c);
r
I am trying to define a function using Rcpp for speedup. The situation is as follows:
I have a package FOO with a lot of C++ code (my own package and currently not using Rcpp) which have defined a set of functions e.g. foo_a and foo_b.
In another package BAR (using Rcpp) I am defining a function (using Rcpp Attributes) where I want to call functions foo_a and foo_b.
How do I solve this? Looking a bit in other posts I get that I have in some way to include header files in FOO and use attribute // [[Rcpp::depends(FOO)]] in BAR, but I seem to miss some points. Any hints on how to do it?
Best Lars
EDIT: Thanks for the comments I liked Kevin Usheys approach and tried to implement it. However, after some coding I realized that I actually don't need functions from FOO but a class and its public functions. I guess that I cannot do the tricks you suggested for a class. I ended up putting the source files of the class from FOO in the BAR src dir (not the best approach since I now have 2 versions of the same code). However for the moment this hack work for me.
I would recommend one of these options:
If foo_a and foo_b are simple enough, just have them as inline functions in headers of FOO and put these headers in FOO/inst/include/FOO.h. Rcpp::depends(FOO) will then include this file when you invoke compileAttributes (or perhaps load_all) on BAR.
Otherwise, consider registering the functions using R's registration model. this is a bit more work, but that's bearable. Writing R extensions has the details. I would suggest putting all the registration logic in FOO so that the client package BAR only has to use it. For example, I'd have foo_a like this in FOO's headers, e.g. in FOO/inst/include/FOO.h:
#ifdef COMPILING_FOO
inline int foo_a(int x, double y, const std::string& z){
typedef int (*Fun)(int, double, const std::string&) ;
static Fun fun = (Fun)R_GetCCallable( "FOO", "foo_a" ) ;
return fun(x,y,z) ;
}
#else
// just declare it
int foo_a(int x, double y, const std::string& z) ;
#endif
and the actual definition of foo_a in some .cpp file in FOO/src:
#define COMPILING_FOO
#include <FOO.h>
int foo_a(int x, double y, const std::string& z){
// do stuff
}
Then, you need to register foo_a using R_RegisterCCallable in the function R_init_FOO:
extern "C" void R_init_FOO( DllInfo* info ){
R_RegisterCCallable( "FOO", "foo_a", (DL_FUNC)foo_a );
}
Another option, in case you don't mind introducing Rcpp into package FOO - follow along with Section 3.5 of Rcpp-attributes and do the following:
Place // [[Rcpp::interfaces(cpp)]] at the top of the .cpp source files containing functions you'd like to be made available to other packages,
Place // [[Rcpp::export]] in front of those functions you would like exported,
Call compileAttributes() in the package directory of FOO to generate files in inst/include that can then be used by package BAR, using // [[Rcpp::depends(FOO)]],
Install package FOO.
If you have this set up correctly, you should be able to call a function with a template like this (supposing foo_a is an exported function from FOO):
// [[Rcpp::depends(FOO)]]
#include <Rcpp.h>
#include <FOO.h>
using namespace Rcpp;
// [[Rcpp::export]]
SEXP some_function() {
return FOO::foo_a();
}
The RcppXts package does just that for a bunch of functions from the well-known xts package.
Edit: Here is some code from xts.
First, xts::src/init.c does the registration via a dozen or so declarations like
R_RegisterCCallable("xts","do_is_ordered",(DL_FUNC) &do_is_ordered);
Second, xts::inst/include/xtsApi.h provides a header for client packages with eg
SEXP attribute_hidden xtsIsOrdered(SEXP x, SEXP increasing, SEXP strictly) {
static SEXP(*fun)(SEXP,SEXP,SEXP) = NULL;
fun = (SEXP(*)(SEXP,SEXP,SEXP)) R_GetCCallable("xts","do_is_ordered");
return fun(x, increasing, strictly);
}
Third, in a client package such as RcppXts we define this (using Rcpp Modules) as
function("xtsIsOrdered",
&xtsIsOrdered,
List::create(Named("x"),
Named("increasing") = true,
Named("strictly") = true),
"Tests whether object is (strictly) (increasing) ordered");
which exposes it to R. We could equally well call the C function xtsIsOrdered from C++ code.
I removed the incorrect earlier comment that functions have to conform to 'SEXP in, SEXP out'.
I am trying to compile a large C++ code (there are a few C files too) on a Linux cluster, having run it for some time on a Mac compiled with g++. On the cluster, I have to use either gcc/4.7.2 or intel/icpc (there is other software on the cluster that only works with those two compilers). I'm a newbie in dealing with compiling/linking problems, so no advice/tips is too simple.
I posted a question here a couple of days ago about a problem with using gcc/4.7.2. I haven't been able to resolve the problem, so now I'm trying icpc. Things have gone surprisingly well, but there is one problem I can't get past.
The problem is that I am getting errors related to "multiple definitions." These are associated with what seems to be a virtual function in a class that is inherited. I didn't write this code. There is a base class (Solver3), a derived class (Solver2), and another derived class (Solver1). The classes solve matrix equations. I can't tell which function is the problem because the error output is quite cryptic (see below; I have no function called "_fileno" and I can't find any generic definition of this term online). But the problem function is probably SolveWithSolver2 because it is the only function in the Solver1 class. I have no clue what could be wrong with it.
This is a bit over my head in terms of C++ knowledge and it is likely I'm making some beginner's mistake. For the past couple of days, I have used Google to search old forum posts. I have tried renaming what seems to be the problem function, I have tried inlining it. I get the same error. The code is very large and only a small part of it was written by me, so I can't post much of it. I will post what seems relevant and can add things if that would be helpful.
Here are the kinds of the errors I'm getting, starting from the first one (I have not posted all of the output):
/code/libraries/libsolver.a(Solver1.o): In
function _fileno(_IO_FILE*)': Solver1.cpp:(.text+0x0): multiple
definition of_fileno(_IO_FILE*)' main.o:main.cpp:(.text+0x1bc0):
first defined here
/code/libraries/libsolver.a(Solver2.o): In
function _fileno(_IO_FILE*)': Solver2.cpp:(.text+0x0): multiple
definition of_fileno(_IO_FILE*)' main.o:main.cpp:(.text+0x1bc0):
first defined here
/code/libraries/libsolver.a(Solver3.o):
In function _fileno(_IO_FILE*)':
Solver3.cpp:(.text+0x0): multiple definition of_fileno(_IO_FILE*)'
main.o:main.cpp:(.text+0x1bc0): first defined here
... And so on
Here is the Solver1 header code:
#ifndef SOLVER1
#define SOLVER1
#include "Solver2.h"
#include "ErrorHandler.h"
#ifdef SOLVER2
namespace code {
class Solver1 : public Solver2 {
public:
Solver1( );
//protected:
virtual void SolveWithSolver2( Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
double tolerance );
private:
double pivot;
};
}
#endif
#endif
Here is the Solver2 header code:
#ifndef SOLVER2_H
#define SOLVER2_H
#include "Solver3.h"
#include "helper.h"
#ifdef SOLVER2
namespace code {
class Solver2: public Solver3 {
public:
Solver2 ();
//protected:
virtual void SolveWithSolver2(Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
double tolerance) = 0;
private:
virtual void SolveEquation(Matrix& A,
std::vector<double>& b,
std::vector<double>& x,
stl_index unknowns);
double Residual(const Matrix& A,
const std::vector<double>& b,
std::vector< double >& x);
double Calculate(const SparseMatrix& A,
const std::vector<double >& b,
const std::vector< double >& x);
double residual;
};
}
#endif
#endif
Reply to Jakob:
Output of:
"grep _fileno" /usr/include/* -R
/usr/include/bits/dirent.h:#define d_fileno d_ino /* Backwards
compatibility. */ grep: warning:
/usr/include/c++/4.3/x86_64-suse-linux/32: recursive directory loop
/usr/include/dirent.h:#if (defined __USE_BSD || defined __USE_MISC) &&
!defined d_fileno /usr/include/dirent.h:# define d_ino d_fileno /*
Backward compatibility. */ /usr/include/lcms.h:# define fileno
_fileno /usr/include/libdwarf/libdwarf.h: Dwarf_Unsigned * /*ret_fileno*/, /usr/include/libio.h:#define _IO_DELETE_DONT_CLOSE
0x40 /* Don't call close(_fileno) on cleanup. */ /usr/include/libio.h:
int _fileno; /usr/include/linux/coda.h: u_int32_t d_fileno; /*
file number of entry */ /usr/include/linux/mtio.h: __kernel_daddr_t
mt_fileno; /* number of current file on tape */
/usr/include/sys/mtio.h: __daddr_t mt_fileno; /* Number of current
file on tape. */ /usr/include/X11/Xw32defs.h:#define fileno _fileno
Edit:
Using Jakob's suggestion about compiler flags (adding -Wl and -z) to my OPTIONS, my error output became much more clear; I got file names, line numbers, and particular errors.
I have now dealt with the problem, in the sense that I can compile that library. But to be honest, I don't really know why the compiler complained to begin with or why my solution worked. The problem involved preprocessor directives, which I confess I know little about. If anyone cares to speculate on what the issue was, it would be interesting to know. I have never run into needing ";" in preprocessor directives before.
This is what "fixed" things (sorry about the bold, large text; can't seem to turn that off):
define SOLVER_C_CONVERSION;
void __cdecl;
endif
This is what it looked like when it was a problem:
define SOLVER_C_CONVERSION void __cdecl
endif
So now that I've fixed that problem, I have one more library to deal with. It is throwing up all kinds of errors that g++ previously ignored. I may bother you all once more later on today if I can't solve them. I'm pretty sure the problem is with my makefile.
To solve the problem with the multiple definitions, the first step would probably be
tracking down the include dependencies,
using the '-M' or the '-H' compiler flag,
e.g. :
gcc -H {use correct include flags here: -I$( include path) } -c Solver1.cpp
This will show you a dependency tree (read top-down )
Then you could figure out, which of the files defines the _fileno symbol.
(e.g by using the grep command)
and finally you could try to understand, why _fileno is defined multiple times.
If you want a nicer dependency output, you could in general try to generate the include dependencies with doxygen.
Alternatively as a workaround you could use following link flags which will prevent the compilation process from failing in case of multiple definitions:
-Wl,-z,multiple
I am working in restructuring a former program which relies heavily on a external library
ChronoEngine.lib
I created a new project which holds the same additional include directories, linkers etc... than the former one
I have the following piece of code in a header file
#ifndef DRAW
#define DRAW
#include "physics/CHsystem.h"
class draw
{
public:
// Change size
static void changeSize(int w, int h);
// World definition
static void drawSky(double halfSize, double red, double green, double blue);
static void drawChair() ;
static void drawCDG() ;
static void drawPlane();
// Geometrical definition
static void drawSphere(ChBody* body);
static void drawBox(ChBody* body);
};
#endif
this is the same header file as in the previous project, but here visual studio does not find the definition of ChBody (which is included in the "physics/CHsystem.h" header file definition - this file includes physics/ChBody.h -)
when i right click on ChBody to find the reference, visual studio finds 5 references (1 is the real definition (from ChBody.h), 4 others are forward references in others files from the library)
how can I tell my program to find the real definition of the class ? Apparently, it is not a problem of being linked to the library, but more like a referencing problem
my main.cpp is only printing something to the screen for the time being, and draw.cpp is empty (i haven't defined the function i am declaring in draw.h for the time being)
Thanks
Best
Vincent
Thanks a lot
Actually that was a fairly easy problem to solve
The problem was coming from the fact that the other classes (such as ChBody) were defined in a namespace
therefore, adding
using namespace <the name of the namespace>;
before the definition of the class and after the #include solves this kind of issues.
Thanks
Best
Vincent
Whenever I start to build my dll I get this error:
fatal error LNK1169: one or more multiply defined symbols found
I think there's nothing wrong with the code because I copied it from a source:
ExoDll1.cpp
#include "stdafx.h"
double BoxArea(double L, double H, double W);
double BoxVolume(double L, double H, double W);
extern "C" __declspec(dllexport)void BoxProperties(double Length, double Height,
double Width, double& Area, double& Volume);
BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserved
)
{
return TRUE;
}
double BoxArea(double L, double H, double W)
{
return 2 * ((L*H) + (L*W) + (H*W));
}
double BoxVolume(double L, double H, double W)
{
return L * H * W;
}
void BoxProperties(double L, double H, double W, double& A, double& V)
{
A = BoxArea(L, H, W);
V = BoxVolume(L, H, W);
}
I tried to create a new project and delete the old ones but same problem still exists.. What seems to be the problem?
This error message cannot appear with only a single translation unit (such as ExoDll1.cpp). You might be, for example, unknowingly trying to compile multiple versions of this code simultaneously.
Examine your project and get rid of any source code that you do not want to compile.
Make sure that you do not have #include "ExoDll1.cpp" anywhere in your project.
This error comes not from the compiler, but from the linker. This means that the compiler found nothing wrong, in particular, no duplicate definitions of symbols in any one compilation unit. However, the linker, which generates the .dll library, loads several compilation units and found duplicate definitions of symbols across compilation units.
This happens if several compilation units contain the same code with external linkage, i.e. if you #included a source code, or if in a header file (which more than one compilation unit #includes) a function was defined and not declared inline.