How to install Eigen library to IAR c/c++ compiler - c++

is it possible to port Eigen, a C++ template library for linear algebra, to IAR workbench for ARM. I have tried to do this while but am getting following compile errors
Error[Pe337]: linkage specification is incompatible with previous "__nounwind __iar_builtin_get_CONTROL" (declared at line 58 of "C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\inc\c\iccarm_builtin.h") C:\Program Files (x86)\IAR Systems\Embedded Workbench 8.3\arm\CMSIS\Core\Include\cmsis_gcc.h 151
This is the entire error I get when I use the preprocessors
__GNUC__
__arm__
if I dont use these preprocessors I get an error from a #error preprocessor
from the Eigen file Macros.h
"error Please tell me what is the equivalent of attribute((aligned(n))) for your compiler"
#if (defined __CUDACC__)
#define EIGEN_ALIGN_TO_BOUNDARY(n) __align__(n)
#elif EIGEN_COMP_GNUC || EIGEN_COMP_PGI || EIGEN_COMP_IBM || EIGEN_COMP_ARM
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#elif EIGEN_COMP_MSVC
#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#elif EIGEN_COMP_SUNCC
// FIXME not sure about this one:
#define EIGEN_ALIGN_TO_BOUNDARY(n) __attribute__((aligned(n)))
#else
//#define EIGEN_ALIGN_TO_BOUNDARY(n) __declspec(align(n))
#error Please tell me what is the equivalent of __attribute__((aligned(n))) for your compiler
#endif
I have it working for visual c++ but not IAR. All includes are added.
These errors change based on the preprocessors I use to try to configure Eigen. Is it possible to use Eigen with IAR?

To add to #chtz answer, here's how I got the EIGEN_ALIGN_TO_BOUNDARY macro to work with IAR, in a way that is consistent with the eigen library:
1: add this to top of Macros.h to identify the IAR ARM compiler
/// \internal EIGEN_COMP_ICCARM set to 1 if the compiler is IAR eWARM
#if defined(__ICCARM__)
#define EIGEN_COMP_ICCARM 1
#else
#define EIGEN_COMP_ICCARM 0
#endif
2: add this case to where EIGEN_ALIGN_TO_BOUNDARY(n) is defined in Macros.h
#elif EIGEN_COMP_ICCARM
#define IAR_STRINGIFY(a) #a
#define IAR_ALIGN_STR(n) IAR_STRINGIFY(data_alignment=n)
#define EIGEN_ALIGN_TO_BOUNDARY(n) _Pragma(IAR_ALIGN_STR(n))
EIGEN_ALIGN_TO_BOUNDARY(n) should now correctly expand to _Pragma("data_alignment=n")

I have now gotten it to build and run. Thank you #chtz for the EIGEN_DONT_ALIGN macro suggestion. This is how I did it. I am unsure however what repercussions this has on the library itself, as in what features this may take away. I did this:
include the directory to where you installed Eigen as the additional includes.
in lines 86, 105, 125, 145 in file DenseStorage.h change the lines
EIGEN_ALIGN_TO_BOUNDARY(8) T array[Size];
to their respective
_Pragma("data_alignment=8") T array[Size];
(pay attention to the number)
in Macros.h , line 665 , comment out the "#error Please tell me what is the"
finally, define the macro EIGEN_DONT_ALIGN in the preprocessor settings.
This is what worked for Eigen 3.3.7

Related

How to detect apple platform in C++? [duplicate]

While reading various C and C++ sources, I have encountered two macros __APPLE__ and __OSX__. I found plenty of use of __OSX__ in various codes, especially those originating from *BSD systems.
However, sometimes I find that testing __OSX__ only is not sufficient and I have to complete tests with __APPLE__ macro.
The Porting Command Line Unix Tools to Mac OS X guides specifies __APPLE__ and additionally __APPLE_CC__ but does not mention __OSX__.
The Porting from GCC guide says:
Use #ifdef __GNUC__ to wrap any GCC-specific code.
Use #ifdef __APPLE_CC__ to wrap any Mac OS X-specific code.
Again, no mention about __OSX__ macro.
What macro is predefined on Mac OS X platform and XCode development environment that should be used to distinguish OSX-specific code in C/C++ programs?
Where is the __OSX__ macro defined? Is it *BSD specific macro?
It all depends.
Each macro specifies something different in meaning.
See: https://developer.apple.com/library/mac/documentation/Porting/Conceptual/PortingUnix/compiling/compiling.html#//apple_ref/doc/uid/TP40002850-SW13
__APPLE__
This macro is defined in any Apple computer.
__APPLE_CC__
This macro is set to an integer that represents the version number of
the compiler. This lets you distinguish, for example, between compilers
based on the same version of GCC, but with different bug fixes or features.
Larger values denote later compilers.
__OSX__
Presumably the OS is a particular variant of OS X
So given the above definitions I would use __APPLE__ to distinguish apple specific code.
Here is a nice list of macros for operating systems.
There's little info on __OSX__ on the web. You'll be safe with __APPLE__.
I normally use __MACH__ for this. It's been defined since the earliest version of OS X (and even before, presumably).
If you want to exclude the possibility that you might be compiling for some other OS that uses the Mach kernel then you can use #scravy's suggestion of:
#if defined(__APPLE__) && defined(__MACH__)
Note also that if you're compiling generic C/C++ code, i.e. no Apple-speacific headers, so you are just interested in pre-defined compiler macros, you can check these as follows:
$ gcc -dM -E - < /dev/null | egrep -i 'os_|mac|apple'
#define __APPLE_CC__ 6000
#define __APPLE__ 1
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 120000
#define __ENVIRONMENT_OS_VERSION_MIN_REQUIRED__ 120000
#define __MACH__ 1
#define __VERSION__ "Apple LLVM 13.1.6 (clang-1316.0.21.2.3)"
#define __apple_build_version__ 13160021
Use
#if defined(__APPLE__) && defined(__MACH__)
to distinguish Apple operating systems.
You can further use TARGET_OS_MAC and TARGET_OS_IPHONE to distinguish between macOS and iOS.
Full example:
#if defined(__APPLE__) && defined(__MACH__)
/* Apple OSX and iOS (Darwin). */
#include <TargetConditionals.h>
#if TARGET_IPHONE_SIMULATOR == 1
/* iOS in Xcode simulator */
#elif TARGET_OS_IPHONE == 1
/* iOS */
#elif TARGET_OS_MAC == 1
/* macOS */
#endif
#endif
Regarding the question of "where does __OSX__ come from?":
Some on-line lists of compiler macros (like this one) list __MACOSX__. Some forum comments (like these) claim __OSX__ exists. These are incorrect. There are no such macros predefined by OSX compilers, but they may be defined by specific project Makefiles and platform-detector scripts like GNU autoconf.
Source: http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system
Update – the above link is broken, see version in web archive: https://web.archive.org/web/20180331065236/http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system#OSXiOSandDarwin
For anyone coming across this question >= 2019, I found there's a header "Availability.h".
In that header, are #defines like:
#define __MAC_10_0 1000
#define __MAC_10_1 1010
#define __MAC_10_2 1020
#define __MAC_10_3 1030
#define __MAC_10_4 1040
#define __MAC_10_5 1050
#define __MAC_10_6 1060
#define __MAC_10_7 1070
#define __MAC_10_8 1080
#define __MAC_10_9 1090
#define __MAC_10_10 101000
#define __MAC_10_10_2 101002
#define __MAC_10_10_3 101003
#define __MAC_10_11 101100
#define __MAC_10_11_2 101102
So you CAN tell if you're compiling on a particular MacOS platform.
See http://nadeausoftware.com/articles/2012/01/c_c_tip_how_use_compiler_predefined_macros_detect_operating_system#OSXiOSandDarwin
#ifdef __APPLE__
#include <TargetConditionals.h>
#if TARGET_OS_MAC
...
#endif /* TARGET_OS_MAC */
#endif /* __APPLE__ */
Note that __OSX__ does NOT exist, at least as of Xcode 9.
Also note that it is #if TARGET_OS_MAC not #ifdef. It is always defined, but is 0 when not macOS.

Feature test macros not working properly in Visual C++

When testing for features in Visual Studio, I found this weird behaviour:
#ifndef __cpp_constexpr
#error Opposite day! //Compiler error
#endif
#define test_macro
#ifndef test_macro
#error But only for feature macros? //No compiler error
#endif
int main() {}
__cpp_constexpr is definitely defined, I used it in the actual program.
From my testing, it seems that with feature macros #ifndef behaves like #ifdef
and vice versa.
Is this a Visual Studio bug, or am I missing something?
Compiled in VS 2017, Visual C++14 or later, with C++17 standard enabled.
P.S. Intellisense is working as intended, it's only the compiler.
You are using incorrect pre-defined macro and pre-proc code. Next code can help:
#if defined(__GNUG__) && (__cplusplus > 201103L)
# define HAS_CONSTEXPR
#elif defined(_MSC_VER) && (_MSC_FULL_VER >= 190024210)
# define HAS_CONSTEXPR
#endif // __GNUG__
#ifndef HAS_CONSTEXPR
# error Opposite day! //Compiler error
#else
# define test_macro
# ifndef test_macro // useless by why not ?
# error But only for feature macros? //No compiler error
# endif
#endif
Suggesting to use boost config library. It is cross compiler, an you can solve it like this:
#ifdef BOOST_NO_CXX11_CONSTEXPR
# error Opposite day! //Compiler error
#endif
And it is going to work for all compilers supported by boost (according to the boost license, you can exam the source code and replicate is in you project)

#error you must define the platform macro

I have a project that I compile and it gives me following errors as:
In file included from c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/PIMain.c:21:0:
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:37:2: error: #error You must define the PLATFORM macro
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:41:10: error: #include expects "FILENAME" or <FILENAME>
c:/acrobatxsdk/Adobe/Acrobat 10 SDK/Version 1/PluginSupport/Headers/API/Environ.h:52:2: error: #error PLATFORM failed to #define ACCB1
The PIMain.c looks like this :
#if WIN_PLATFORM
#include "WinCalls.h"
#elif MAC_PLATFORM
#include "MacCalls.h"
#elif UNIX_PLATFORM
#include "UnixCalls.h"
#else
#error platform not defined
#endif
I have come to know that the only amendment if required is to be made in Environ.h , can some one suggest how?
Environ.h is looking for the PLATFORM directive and there is a preprocessor or compile time flag to "throw" an error if you do not define it. See how the #error directive works here (MSDN link).
I found the code for Environ.h:
#ifndef PLATFORM
#ifdef WIN_ENV
#define PLATFORM "winpltfm.h"
#elif __OS2__
#define PLATFORM "os2pltfm.h"
#elif defined(unix) || defined(__unix)
#define PLATFORM "UnixPlatform.h"
#else
#error You must define the PLATFORM macro
#endif
#endif
You apparently are not running on a supported platform.

how to undefine _MSC_VER?

I work in Visual Studio but my project is for a POSIX-based environment (marmalade sdk). In this project, the release
build is compiled with gcc for ARM but the debug version works on windows and is compiled by MS compiler. Also this environmet has its own implementation of STL and other standard libraries.
Many of these c++ librares have code like this:
#if defined( _MSC_VER )
#include <Windows.h>
#else
#include <pthread.h>
#endif
Is it possible to undefine the _MSC_VER macro? - So that the C++ libraries will detect a POSIX system here.
_MSC_VER is (and always should be) defined when compiling with the Microsoft compiler so that it "evaluates to the major and minor number components of the compiler's version number". Therefore, the code is using the wrong macro test, since it will always be defined to some value for your compiler regardless of the Windows environment differences.
Rather than destroy the definition of _MSC_VER (which could lead to other problems if any code really does want to know the compiler version), what you really should do instead is to correct the condition so that a more appropriate macro test is used that distinguishes between the kinds of Windows environments that you might encounter.
See the more complete list of predefined macros you could consider here
You could either replace the condition ...
#if someOtherConditionGoesHere
... or extend it with additional conditions, e.g.
#if defined(_MSC_VER) && someOtherConditionGoesHere
Of course:
#undef _MSC_VER
#if defined( _MSC_VER )
#include <Windows.h>
#else
#include <pthread.h>
#endif
Or, #undef it before you include the file where _MSC_VER is used.

C++ preprocessor unexpected compilation errors

Please look at the following file: (it is a complete file)
#ifndef TEES_ALGORITHM_LIBRARY_WRAPPER_H
#define TEES_ALGORITHM_LIBRARY_WRAPPER_H
#ifdef _TEES_COMPILE_AS_LIB
#include <dfa\Includes\DFC_algorithms.hpp>
#include <DFA\FuzzyClassifier\FuzzyAlgorithmIntialization\InitFuzzyAlgorithm.hpp>
typedef teesalgorithm::tees_fuzzy_algorithms algorithms_switchyard_class;
#else
#include <DFA\Includes\commercial_algorithms.hpp>
//An incomplete class to hide implementation
class algorithms_switchyard_class;
#endif
class AlgorithmLibraryWrapper {
algorithms_switchyard_class * algorithmPtr_;
typedef teesalgorithm::tees_paramObj paramObj_type;
typedef teesalgorithm::tees_errorObj errorObj_type;
typedef teesalgorithm::tees_statusObj statusObj_type;
typedef teesalgorithm::tees_dataObj dataObj_type;
typedef teesalgorithm::tees_outputObj outputObj_type;
public:
AlgorithmLibraryWrapper(const std::string& sAlgName, paramObj_type& paramObj, errorObj_type& errObj, statusObj_type& statusObj, const char* sFilePath);
static bool dataReader(const std::string& sFileName, dataObj_type& dataObj, errorObj_type& errObj, statusObj_type& statusObj);
bool runalgorithm(const dataObj_type& dataObj, outputObj_type& outObj, errorObj_type& errObj, statusObj_type& statusObj);
~AlgorithmLibraryWrapper();
};
#ifdef _TEES_USE_COMPILED_ALGORITHM_LIB
# ifdef _MSC_VER
#if _MSC_VER < 1400 // If VC 2003
#ifdef _DEBUG
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#else
#error No AlgorithmLibWrapper libraries compiled for this version of VC
#endif
#elif defined(UNDER_CE) // Win CE
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperCEd" )
#else
#pragma comment( lib, "AlgorithmLibWrapperCE" )
#endif
#else // If VC 2005
#ifdef _DEBUG
#pragma comment( lib, "AlgorithmLibWrapperd" )
#else
#pragma comment( lib, "AlgorithmLibWrapper" )
#endif
#endif
#endif
#endif
#endif //TEES_ALGORITHM_LIBRARY_WRAPPER_H
I am getting the following errors; I don't know why. I manually counted the preprocessor directives also.
AlgorithmLibraryWrapper.hpp:10:1: unterminated #ifdef
AlgorithmLibraryWrapper.hpp:7:1: unterminated #ifndef
I am using the poor vxWorks gcc compiler. Please let me know if the fault is mine or the compiler's.
It could be that the problem is in the included files (if there actually are unbalaced #if/#endifs.
I would try preprocessing with another compiler. You can use gcc for that, doesn't matter it wouldn't compile. Just get gcc (or MinGW if you're on Windows) and run
cpp -Iinclude_direcories your_file
Or, if you don't like gcc, get MSVC Express edition. Again, you can preprocess code that even doesn't compile, so no problem with nonworking library etc.
Most compilers have an option that will give you the output from the preprocessor so you can check what it's doing. For example,
gcc -E file.c >file.preproc
will give you the pre-processed source so you can check the balancing of #if against #endif.
At a guess, one of the files you are #including from this one has a mismatched #ifdef/#endif pair. You need to look at all the files (as the preprocesor does), not just this one.
As others have noted, this is most likely due to mismatched include guards.
If the files you are including are under your control (i.e. not part of a 3rd party closed source library), you could consider replacing the #ifndef et. al. guards (which are used to prevent multiple inclusion) with #pragma once. This will eliminate the possibility of having mismatched preprocessor directives.
One caveat of this is that pragma once is non-standard, so it will only work if your compiler supports it.
I have tried to compile your source using vs 6.0 but did not get the error you have mentioned. As others said may be the error is coming from the included header file . For me to get your code compiled i need to comment the above header.
Please check the above header once.
I'd debug this by commenting out sections one by one and trying to identify which section is causing the error.
It could be your compiler does not like the nested #ifdefs or does not interpret the syntax correctly. Maybe it doesn't like the #pragmas.
This is a long shot, but in your source file you have the following line:
# ifdef _MSC_VER
where there is whitespace between the '#' character and the directive name (ifdef). This is valid in C/C++; however, it's not too commonly seen so I wouldn't be very surprised if the odd compiler choked on it.