I added several different versions of Eigen to default including directory of Visual C++.
But I got collapse problem when using LDLT (Cholesky decomposition) for some of the testing numerical examples.
So I want to determine which version is actually active when debugging the code.
Is there any function which can indicate the current active Eigen version number?
This answer is only a summary from the comments above:
At compile-time you have EIGEN_WORLD_VERSION, EIGEN_MAJOR_VERSION
and EIGEN_MINOR_VERSION, you can easily embed this information in
your application.
3.1.91 sounds like a beta version of 3.2.
The version number macros are defined in Macros.h located at
\Eigen\src\Core\util\.
In order to check the version number of Eigen C++ template library, just type
dpkg -p libeigen3-dev
in the terminal.
Or just type
pkg-config --modversion eigen3
you will get the Eigen version.
Although it is not the goal of the OP, people finding this question may be interested in checking if the version is equal to are newer than a specific release for compatibility reasons with different versions of Eigen. This can be done more easily using the EIGEN_VERSION_AT_LEAST(x, y, z) macro as follows:
#if EIGEN_VERSION_AT_LEAST(3,3,0)
// Implementation for Eigen 3.3.0 and newer
#else
// Implementation for older Eigen versions
#endif
This macro is also defined in Eigen/src/Core/util/Macros.h and uses EIGEN_WORLD_VERSION, EIGEN_MAJOR_VERSION and EIGEN_MINOR_VERSION internally.
On Linux:
grep "#define EIGEN_[^_]*_VERSION" /usr/local/include/eigen3/Eigen/src/Core/util/Macros.h
You'll get something like:
#define EIGEN_WORLD_VERSION 3
#define EIGEN_MAJOR_VERSION 3
#define EIGEN_MINOR_VERSION 7
It means version 3.3.7
Related
I have some code that is heavily dependent on Eigen. I would like to optimize it with CUDA, but when I am compiling I get:
[tcai4#golubh4 Try1]$ nvcc conv_parallel.cu -I /home/tcai4/project-cse/Try1 -lfftw3 -o conv.o
In file included from Eigen/Dense:1,
from Eigen/Eigen:1,
from functions.h:8,
from conv_parallel.cu:10:
Eigen/Core:44:34: error: math_functions.hpp: No such file or directory
I think math_functions.hpp is a file from CUDA. Can someone help me figure out why nvcc cannot find it?
edit: I am using CUDA 5.5 and Eigen 3.3, except from linking Eigen and fftw3 library, I did not use any other flags(as you can see from my code).
I encountered this issue while building TensorFlow 1.4.1 with Cuda 9.1, and strangely math_functions.hpp existed only in include/crt.
Creating a symlink from cuda/include/math_functions.hpp to cuda/include/crt/math_functions.hpp fixed the issue:
ln -s /usr/local/cuda/include/crt/math_functions.hpp /usr/local/cuda/include/math_functions.hpp
The reason nvcc cannot find the file in question is because that file is part of the CUDA Math library, which was introduced in CUDA 6. Your almost 4 year old version of CUDA predates the release of the Math library. Your CUDA version doesn't contain said file.
You should, therefore, assume that what you are trying to do cannot work without first updating to a newer version of the CUDA toolkit.
Creating symlink sometimes causes other complication.
You can try replacing
// We need math_functions.hpp to ensure that that EIGEN_USING_STD_MATH macro
// works properly on the device side
#include <math_functions.hpp>
with
// We need cuda_runtime.h to ensure that that EIGEN_USING_STD_MATH macro
// works properly on the device side
#include <cuda_runtime.h>
in
/usr/include/eigen3/Eigen/Core,
which works for me.
The reason why "math_functions.hpp" cannot be found is because "math_functions.hpp" has been renamed to "math_functions.h". So you just need to go to
/usr/include/eigen3/Eigen/Core
and change "math_functions.hpp" to "math_functions.h"
I have a C++ application using GTKmm version 3.
From one version of the library to another, some method definition change so I would like to handle them in order to allow my sources to compile with a previous and actual version of GTKmm.
When I have written a kernel module, I did the same thing using conditional operators like the following:
#if LINUX_VERSION_CODE >= KERNEL_VERSION(3,6,0)
// Something is done when kernel version is 3.6 or higher
#else
// Something else is done for older versions
#endif
So the question is: is this possible in C++ and GTKMM ?
Yes - gtkmm has the defines GTKMM_MAJOR_VERSION, GTKMM_MINOR_VERSION, and GTKMM_MICRO_VERSION.
I would like to write a "portable" C++ library in Clang. "Portable" means that I detect (in C preprocessor) what C++ features are available in the compilation environment and use these features or provide my workarounds. This is similar to what Boost libraries are doing.
However, the presence of some features depends not on the language, but on the Standard Library implementation. In particular I am interested in:
type traits (which of them are available and with what spelling)
if initializer_list being constexpr.
I find this problematic because Clang by default does not use its own Standard Library implementation: it uses libstdc++. While Clang has predefined preprocessor macros __GNUC__, __GNUC_MINOR__, __GNUC_PATCHLEVEL__, they are hardcoded to values 4, 2, 1 respectively, and they tell me little about the available libstdc++ features.
How can I check in Clang preprocessor what version of libstdc++ it is using?
Clang does come with its own standard library implementation, it's called libc++. You can use it by adding -stdlib=libc++ to your compile command.
That being said, there are various ways to check Clang/libstdc++ C++ support:
Clang has the __has_feature macro (and friends) that can be used to detect language features and language extenstions.
Libstdc++ has its own version macros, see the documentation. You'll need to include a libstdc++ header to get these defined though.
GCC has its version macros which you already discovered, but those would need to be manually compared to the documentation.
And also, this took me 2 minutes of googling.
This is what I think would help. It prints the value of the _LIBCPP_VERSION macro:
#include <iostream>
#include <string>
using namespace std;
int main(int argc, const char * argv[])
{
cout<<"Value = "<<_LIBCPP_VERSION<<endl;
return 0;
}
Compile it again the version of clang you want the info for.
I'm trying to build the Solar-System (C++) Panda3D example for version 1.8. The problem I'm having is that when I compile it I get an error:
clr; g++ -c ./solar_system/tut_solar_system.cpp -o ss.o -fPIC -L/usr/lib/panda3d -I/usr/include/python2.7 -I/usr/include/panda3d
./solar_system/../p3util/cOnscreenText.h:75:22: error: ‘Colorf’ does not name a type
I have tried editing that file and including glew, glext, and glut (provided by my distro), as well as the "panda_glext" provided by Panda3D - none of those provides ColorF. (I am using archlinux and I have glew, glext, and freeglut.)
I don't know where to start looking. Google has failed me! Does anyone know where ColorF is defined?
It is called LColorf, and it is a typedef for LVecBase4f, which is the generic Panda3D class for four-component floating-point values (such as vectors and colours). The 'f' stands for 'float'; there is also an LColord typedef available.
This was a change in Panda3D 1.8.0. Before 1.8.0, it was called Colorf (without the leading L). Presumably, the sample programs you downloaded were designed for an earlier version. You may change the relevant sample program to use LColorf, or you may choose to add the following before including these headers:
#if PANDA_NUMERIC_VERSION >= 1008000
#define Colorf LColorf
#endif
(Alternatively, you could use a typedef if that is what you prefer.)
For the record, the appropriate header file to include to make the LColorf symbol available is luse.h. You should not include panda_glext.h, it is only used by the OpenGL renderer.
I am trying to implement backtrace functionality for a large framework, which is used for different platforms and OS'es. In some of them, it is linked against glibc, while in the other, something different (eg. uclibc) is used. backtrace() function exists only in the former.
Is there any way to tell whether glibc is used? Any #define? I was unable to find an answer in glibc manual. I know I can't have linking-time information during compilation, but I guess include files have to differ. At least backtrace have to be declared somewhere.
I would like to check it without being forced to pass explicit flags to the compiler.
Include features.h, it contains the macros you need, e.g.
#define __GNU_LIBRARY__ 6
/* Major and minor version number of the GNU C library package. Use
these macros to test for features in specific releases. */
#define __GLIBC__ 2
#define __GLIBC_MINOR__ 4
There are the #defines __GNU_LIBRARY__, __GLIBC__ and __GLIBC_MINOR__ (6, 2 and 11 on my system with glibc-2.11) in features.h.
Checking for preprocessor macros is not a good solution. uClibc and possibly other libc implementations define macros to mimic glibc (without providing all of its bloated functionality) for much the same reasons that all browsers include "Mozilla" in their User-Agent strings: broken programs that expect to see glibc and turn off lots of features if they don't see it.
Instead you should write a configure script to probe for backtrace and use it only if it's available.
Empirically, both of the following compile and run fine on GCC 6.4:
#include <stdio.h>
int main(void) {
#ifdef __GLIBC__
puts("__GLIBC__");
#endif
return 0;
}
and:
int main(void) {
#ifdef __GLIBC__
puts("__GLIBC__");
#endif
return 0;
}
but only the first produces output of course.
This must mean that __GLIBC__ comes from stdio.h which must include features.h, see also: What is the purpose of features.h header?
Therefore, strictly speaking, __GLIBC__ by itself is not a clear indication that glibc is used, since even without headers, GCC already embeds runtime objects such as crt1.o in the finale executable, and those come from glibc.
So the main missing question is: does glibc guarantee that features.h gets included by every header? I could not find a clear documentation quote. TODO.
#if defined(__GLIBC__) && !defined(__UCLIBC__) && !defined(__MUSL__)
This is getting a bit ugly and syntactically ambiguous, but useful.