I'm using MacOS 10.15.7 with Xcode 12.4, I want to use Armadillo library in my iOS Swift project. So first I installed Armadillo through Homebrew.
Armadillo was installed in path /usr/local/Cellar/armadillo/
I found header files in path /usr/local/Cellar/armadillo/10.5.1/include and library files in path /usr/local/Cellar/armadillo/10.5.1/lib
In Xcode project, Build settings I provided the above paths in Header Search path and Library search path.
I'm getting below three errors.
/usr/local/Cellar/armadillo/10.5.1/include/armadillo_bits/compiler_check.hpp:50:4: error: "*** C++11 compiler required; enable C++11 mode in your compiler, or use an earlier version of Armadillo"
/usr/local/Cellar/armadillo/10.5.1/include/armadillo:23:10: error: 'cstdlib' file not found #include <cstdlib>
<unknown>:0: error: failed to emit precompiled header
Not sure how to proceed.. Any suggestions ???
You will not be able to do this easily. Swift does not yet support C++ interop, but this is a long term goal. You can read about in the C++ Interop Manifesto in the Swift git repo. The best you will be able to do right now is write an extern "C" wrapper in C++ around any C++ functions you want to call, and then import your wrapper into Swift. Since you're using an Xcode project, I would recommend trying something like this.
Alternatively, depending on what you need Armadillo for, you might be able to by away without it. If you just need to do linear algebra, Apple includes LAPACK (see here) and BLAS (see here) inside Accelerate, which is available on all Apple platforms without installing anything. This might even be familiar to you because Armadillo does its matrix decompositions through LAPACK. There's also Quadrature (see here) if you are looking for integration. I've had good experiences with each of these.
Related
I am attempting to make a simple ToolChain for the Borland 4.5 compiler with the Pharlap extender based on instructions at the Apache website: https://netbeans.apache.org/kb/docs/cnd/toolchain.html
I am basing the ToolChain on MinGW so that I can use those tools for make.
I cannot get the new toolset to find the Borland compilers the way MinGW is automatically discovered. If I use g++ as the compiler name, Netbeans finds that OK. The issue seems to be with the directory. I'm assuming an installation directory of C:\BC45\BIN and attempting to find BCC32.EXE in that directory.
When I run (clean, build, then run) the test installation of the netbeans module, I see my new toolchain in C/C++, but the field for the C++ compiler is always empty unless I specify a program in the c:\mingw\bin (base) directory.
I have tried variations on the following in my cpp xml file, making sure from time to time that it works just fine with g++ as the name:
<cpp>
<compiler name="bcc32.exe"/>
<recognizer pattern=".*[\\/]bc45.*[\\/]bin[\\/]?$"/>
I haven't found documents beyond the Apache website. I'm basing my guesses on what I have found in: %appdata%\NetBeans\12.4\config\CND\ToolChain\MinGW.xml
The XML above was OK as far as it goes. The example at apache.org only fills in the subclass of c++ (cpp). When I also subclassed the c, assembler, and linker, I ended up with the fields in the C++ options automatically populating as expected.
vcc4n (https://sourceforge.net/p/vcc4n/wiki/Home/) has a good example of implementing the four important classes for those build tools, but really just continuing the example to create and fill in the additional XML as specified in layer.xml is straightforward enough.
I am trying to load a 3rd-party library (.so file) into MATLAB under RHEL.
I am getting an error: undefined:symbol: _intel_fast_memmove.
From Symbol lookup error: _FileName_: undefined symbol: _intel_fast_memmove it seems like I need to add a sub-directory of /opt/intel to my LD_LIBRARY_PATH environment variable, but I don't have an /opt/intel directory.
UPDATE:
MATLAB said that the problem came when trying to load libifcoremt.so.5. I have since installed Intel's Redistributable Libraries and all that did was call Intel's version of libifcoremt.so.5 but still looked for _intel_fast_memmove (but still didn't find it). So now I'm thinking that there must be some other "definitions" file somewhere that I'm missing.
It took me a few days, but I was able to figure out what was going on.
In the end, there were two problems:
I was missing some libraries -- not the ones that I mention in my question, but Intel's Redistributable Libraries.
Even with all of the libraries on my computer, MATLAB was still using an older version of the some of the .os files.
I failed to mention in my question that while the 3rd-party library is fairly recent, I was calling it from MATLAB 2012B because I needed to integrate it with a software package that doesn't work correctly with later MATLAB versions. My apologies for that omission -- it turns out to be a critical piece of the puzzle.
While diagnosing this issue, I learned that MATLAB has it's own copy of the Intel libraries in the <MATLAB>/sys/os/glnxa64 sub-directory and that it creates an internal version of LD_LIBRARY_PATH that points to its internal version before the LD_LIBRARY_PATH that it imports from the Linux OS. Since the version of MATLAB I'm using is 6 years old, so is it's Intel library, which doesn't contain some symbols defined in the new library, such as intel_fast_memmove.
To get the integrated system up and running, I instituted a workaround to rename the sys/os/glnxa64 before calling the 3rd-party library so that MATLAB found the newer Intel library instead of the MATLAB 2012B version. And then named it back when done (without that directory, MATLAB won't start).
Note: I first tried editing the value of LD_LIBRARY_PATH inside MATLAB 2012B to prefer the new Intel library, but found that even though the external variable value changed, loadlibrary still used the original value that placed MATLAB's library first on the path.
I created a .mex file of a MATLAB file test.m from MATLAB R2012b using MATLAB coder.
I got the output file test_mex.mexa64. I was hoping to use this .mex file in MATLAB 7.5.0 (R2007b) but it shows the following error.
Invalid MEX-file '/work/sreekanthl/test_mex.mexa64': libmwblascompat32.so:
cannot open shared object file: No such file or directory.
How can I make this .mex file work in 7.5.0 (R2007b)?
I agree with David Kelley's answer for general MEX files but there is a special consideration for MATLAB Coder generated MEX files. MATLAB Coder generated MEX code is expected to be forward compatible but generally is not expected to be backward compatible. In other words, you are expected to be able to use such MEX code in a newer release than the one with which it was generated, however using the code in an earlier release cannot be guaranteed to work.
The reason for this is that the MEX code uses various runtime libraries which ship with MATLAB. These libraries advance over time and the MEX file from the newer version may depend on features that the older libraries do not provide, or even on a new library which does not exist in the older release as you are seeing here.
If you want to create MEX code that is compatible with earlier releases, you could generate a standalone target such as a static library or a shared library (LIB or DLL respectively for MATLAB Coder), and either:
Try to use loadlibrary to call the generated code in MATLAB
Write a generic MEX interface for it and compile that MEX code in the older release
These options are more work but should enable you to create a MEX file or shared library usable in an older release.
While TMW says that mex functions are usually compatible between versions, it's not officially supported and quite common to run into issues with it.
The only reliable option is to simply recompile the generated source code that Matlab coder created (i.e., the C code) in the version you want to run it in using the mex function.
I created a C++ shared library project in Ubuntu with compiler g++ 4.6.
Some of the dependency libraries expects some preprocessor commands about compiler and operating system to properly compile, like
#elif defined(__GNUC__) || defined(__llvm__) || defined(__clang__)
However Eclipse doesn't define them automatically (at least the version I'm using), is there a setting or option in Eclipse which does this for me ?
You can set preprocessor defines in the project properties: .
However, in your case, I wouldn't use these, as they shouldn't be project specific (due to them being compiler specific). I actually think you're looking for these. I'm not sure for llvm/clang (there are ones, but I don't remember them right now), but for GCC you should use the macro __GNUC__ which will be defined by the compiler itself, without you having to worry about it. The leading underscores tell you, that they aren't part of the standard and not necessarily defined when using another compiler (e.g. MSVC).
For cross platform usage of vsprintf_s:
// this will be set on Visual Studio only, so this code is added for all other compilers
#ifndef _MSC_VER
#define vsprintf_s(b,l,f,v) vsprintf(b,f,v);
#endif
But in general, try to use functions that are available on all platforms (for this example, in this case use vsnprintf() instead).
For being more specific, I'm wondering if it's possible to compile a .c and a .pl with the gnu prolog compiler but link them with Apple LLVM compiler along with the rest of an iOS project for being able to use prolog in an iOS app.
When you link files, you do that using a linker, not a compiler. Some times the compilers call the linker for you so you don't have to do that, that is why you think that the compilers are doing the linking.
This is how you link some object files together:
ld -o myprogram program.o program1.o ...
For more information on ld look here.
EDIT: If you are going to use your prolog .o files in an iOS project, you must be sure that you compile your prolog code for the same plattform as the iOS is running on, let's say ARM.