I do compile Ipopt with openblas using the linkage: ./configure --with-blas-incdir="-L/home/moritz/build/CoinIpopt_test/ThirdParty/openblas/include/" --with-blas-lib="-L/home/moritz/build/CoinIpopt_test/ThirdParty/openblas/lib/ -libopenblas_sandybridgep-r0.2.14.a"
If I do not define any specific LAPACK library, Ipopt automatically uses the LAPACK from netlib. Does openplas comes with its own optimized LAPACK implementation ?
If I use --with-lapack-incdir="-L/home/moritz/build/CoinIpopt_test/ThirdParty/openblas/include/" --with-lapack-lib="-L/home/moritz/build/CoinIpopt_test/ThirdParty/openblas/lib/"
make fails because some Lapack routines could not be resolved e.g undefined reference todpotrs_
At least there is the filelapacke.hin theincludefolder but there are not LAPACK libraries in thelib` folder.
I found this issue on GitHub stating:
OK, I think I figured it out...
You can make OpenBLAS build without including LAPACK in it, by >specifying NO_LAPACK=1 on the make command line. By default, it >includes a full LAPACK lib (with some parts optimized).
But if this is the case where are the libs ?
Should I compile LAPACK against openblas ?
I would highly appreciate it, if someone could shed some light on this issue.
On the changelog.txt in the OpenBLAS folder, it said
* Patched LAPACK to fix bug 114, 117, 118.
(http://www.netlib.org/lapack/bug_list.html)
Also check the source code layout at this page, and this page said: "OpenBLAS implements optimized versions of some LAPACK functions"
Based on these, I think OpenBLAS download Lapack from netlib and then optimized some of it. Are you able to find an alternative though?
BTW, LAPACK is only required if you intend to use the quasi-Newton options in Ipopt
Related
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.
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.
In a Java project I am using matrix-toolkits-java (MTJ) for efficient matrix multiplication. This relies on netlib-java, which in turn relies on an optimized implementation of BLAS and LAPACK installed on the machine. It specifically looks for /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 to find these libraries.
When installing blas and lapack via Yum, we get symbolic links /usr/lib64/libblas.so.3 and /usr/lib64/liblapack.so.3 pointing to the .so files from the reference blas and lapack installed via Yum.
Now we want to use implementations that are faster than the reference ones, in my case OpenBLAS. Irrelevant of whether I compile that myself, or install it via Yum, I end up with /usr/lib64/libopenblas-r0.2.18.so.
Now, according to any guide on the internet I am supposed to replace the symlinks to the reference implementation with symlinks to the OpenBLAS implementation, ending up with something like this:
libblas.so.3 -> libopenblas-r0.2.18.so
liblapack.so.3 -> libopenblas-r0.2.18.so
Okay, I can do that! I can do that with ln, or via alternatives. And if I do that, my code is happily using the fast OpenBLAS.
However, when ldconfig runs my awesome symbolic links are gone, they are overwritten by the reference BLAS and LAPACK installations. And then my software is sad and slow again.
So my question is, how to install OpenBLAS on CentOS/Fedora in such a way that running ldconfig will not destroy it? I can not remove the blas and lapack packages, as other clients of the host might rely on it. Rather I would somehow make the OS understand that OpenBLAS is an drop-in alternative to blas and lapack.
This article proposes installing openblas-compat via Yum. That fixes the issue for me. After installing the default blas package my software was still using OpenBLAS.
i don't think this behaviour is something that can be avoided without removing the reference implementations.
if you need to manually rebuild the ld.so.cache, you can run ldconfig -X to avoid updating links.
apart from that you will most likely have to create a custom script to restore the symbolic links to openblas after ldconfig updated the links
I am using cygwin64 installed in C:/cygwin64, with eclipse and GTK2.0. Although include <gtk/gtk.h> is in the source, and C:/cygwin64/usr/include/gtk-2.0 is in the include path (I added it), many things in a gtk2 simple example are still not recognized, such as GtkWidget, gpointer, and GTK_WINDOW_TOPLEVEL. I got the whole of GTK2 via cygwin setup. I was and am reluctant to download all of GTK2 separately and install it on top of cygwin, since wouldn't it result in multiple locations for the same thing? How may I resolve it? Would separate download and installation not result in redundancy, and possible alternate or even conflicting aliases?
A secondary question: I am confused about the general library requirements. Cygwin is a package which runs on Windows, but offers a Linux/unix-like interface. This argues that the libraries should be .a and .so. But since it is Windows, I also see a lot of .dll within C:\cygwin64. Normally, I would expect that only cygwin proper would contain .dll files and all other code would be Linux code. Yet that seems not to be the case. Often, I see both .dll and .so libraries with the same base name. Which is it, dll, or .so and .a, etc?
A tertiary question relating to the one above involves the main gtk2 library. The projected usage is not developing these programs, but just using GTK2 in applications. The documentation says to use glib, but there are many. Some are glib2.so, others glib2, or cygglib2.0.0.dll. Which of these is appropriate? or some other library? How do I set the exclipse LIBRARY path? (Since I unexpectedly encountered the problem with gtk.h, I am trying to anticipate and head off the corresponding problem with the library implementing gtk2.)
I use MATLAB 2012a. I need to compile a mex file in my program. Everything works fine with Microsoft SDK 7.1 but I need a minor compiler in order to work my program in other computers. Suggested compilers on MathWorks website are compilers that need to be installed as packages. Is there any compilers that work stand-alone and don't need to be installed?
You can use MinGW, but it is not straightforward. See this Q&A. The accepted answer suggest to compile and link MEX files outside of MATLAB, which is fine, but it's simple to just create mexopts.bat to do this.
A good mexopts.bat for MING is hosted here. Pick a MINGW distribution from win-builds and set the paths in mexopts. Then you can use mex -setup with this file.
gnumex is a disaster, IMO.