Is there a way to obtain the version of liblapack.a? - lapack

I installed lapack 3.4.2 and 3.5.0 by compiling them with cmake. In my installation dir of lapack 3.5.0 I find a file ./pkgconfig/lapack.pc saying Version: 3.4.2. So I'm not sure I really installed lapack 3.5.0 there.
Is there a way to obtain the version of lapack directly form the lib liblapack.a (or LAPACK.lib under Windows) ? For example from a routine in the library or with a specific tool ?

The lapack function ilaver() is made for you !
Its prototype is self-explaining :
subroutine ilaver ( integer VERS_MAJOR,
integer VERS_MINOR,
integer VERS_PATCH
)
Here are two programs demonstrating how to use it :
in a fortran program, complied by gcc main.f90 -o main -llapack
PROGRAM VER
IMPLICIT NONE
INTEGER major, minor, patch
CALL ilaver( major,minor, patch )
WRITE(*,*) "LAPACK ",major,".",minor,".",patch
END PROGRAM VER
In a c program, compiled by gcc main.c -o main -llapack
#include <stdio.h>
extern ilaver_(int* major,int* minor,int* patch);
int main()
{
int major=0;
int minor=0;
int patch=0;
ilaver_(&major,&minor,&patch);
printf("lapack %d.%d.%d\n",major,minor,patch);
}

If you don't want to compile anything, you can do this in Python:
ATL-MBP-MAC4:~ dmcdonald$ python3
Python 3.4.2 (default, Jan 29 2015, 06:34:22)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from ctypes import *
>>> from ctypes.util import *
>>> lapack = CDLL(find_library("lapack"))
>>> major, minor, patch = c_int(), c_int(), c_int()
>>> lapack.ilaver(byref(major), byref(minor), byref(patch))
0
>>> print("{0}.{1}.{2}".format(major.value, minor.value, patch.value))
3.2.1

Related

swift-lldb compilation fails with c++11 error

I am trying to compile swift-lldb on Ubuntu 14.04 (following instructions from https://github.com/apple/swift-lldb). I have the following dependencies installed:
Clang-3.5
Cmake version 3.5.2
Python version 2.7.6
On running the build script step which is lldb/scripts/build-swift-cmake.py --test, I am seeing the following error:
CMake Warning at cmake/modules/HandleLLVMOptions.cmake:185 (message):
-fPIC is not supported.
Call Stack (most recent call first):
cmake/modules/HandleLLVMOptions.cmake:216 (add_flag_or_print_warning)
CMakeLists.txt:616 (include)
CMake Error at cmake/modules/HandleLLVMOptions.cmake:429 (message):
LLVM requires C++11 support but the '-std=c++11' flag isn't supported.
Call Stack (most recent call first):
CMakeLists.txt:616 (include)
I have defined environment variables CC and CXX to point to the clang C and C++ compilers.
root:/myswift# echo $CC
/usr/bin/clang
root:/myswift# echo $CXX
/usr/bin/clang++
I also found in the clang documentation that c++11 is supported by clang-3.5. Not sure what I am missing here. Can someone please help?
clang-4.0 mentioned as part of the installation should support the -std=c++11 flag (just tested clang-4.0.1). However, upgrading to clang-6.0 seems to solve this build process error.
Running cmake directly in the automatically created build directory (by the swift build scripts) could be used to investigate the build failure in more detail. To specify compilers here, rather than setting CC and CXX environment variables (which works well for GNU configure scripts), compilers can be set for cmake via
cmake -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++ path_to_src_or_build_directory
An existing CMakeCache.txt might have to be removed, so that the above parameters are honored.
A problem with clang++ installations that I have observed is that clang++ cannot find C++ headers (i.e. if C++ headers are in non-standard locations other than /usr/include, unlikely in the case of Ubuntu though). In case /usr/bin/clang++ cannot compile a simple program like
#include <iostream>
using namespace std;
int main() {
cout << "hello" << endl;
return 0;
}
not being able to find the iostream include file, it might help to set --gcc-toolchain=/pathtoaworkinggcc, where pathtoaworkinggcc should include include, lib, bin, etc. of a working C++ compiler (possibly g++ in the case of a Ubuntu installation).

undefined reference to `google::protobuf::internal::fixed_address_empty_string'

I am using Ubuntu 14.04. And I am trying to use mex command from MATLAB, which links caffe library and protobuf. However, the problem happens when I run this script:
mex imageset_to_leveldb.cpp -lcaffe -lglog -lgflags -lprotobuf -lleveldb -llmdb ...
-L/home/wei/Caffe/build/lib ...
-I/home/wei/Caffe/build/src/caffe/proto
mex serialized_pairs_to_leveldb.cpp -lcaffe -lglog -lgflags -lprotobuf -lleveldb -llmdb ...
-L/home/wei/Caffe/build/lib ...
-I/home/wei/Caffe/build/src/caffe/proto
It returns the error:
Building with 'g++'.
Warning: You are using gcc version '4.8.4'. The version of gcc is not supported. The
version currently supported with MEX is '4.7.x'. For a list of currently supported
compilers see: http://www.mathworks.com/support/compilers/current_release.
> In compile (line 2)
Error using mex
/tmp/mex_3078197848859966_35312/imageset_to_leveldb.o: In function `process(unsigned
char*, int, int, int, char const*)':
imageset_to_leveldb.cpp:(.text+0x5dd): undefined reference to
`google::protobuf::internal::fixed_address_empty_string'
collect2: error: ld returned 1 exit status
It seems cannot find protobuf lib file. So I check the protobuf version and path as:
>>> import google.protobuf
>>> print google.protobuf.__version__
3.1.0.post1
>>> google.protobuf
<module 'google.protobuf' from '/usr/local/lib/python2.7/dist-packages/google/protobuf/__init__.pyc'>
I use Anaconda. However, the version check above is from outside of Anaconda Python. In conda environment, I do not have protobuf.
I compiled caffe inside of conda environment, which passes all the test with no error.
I google it, which suggests to conda install protobuf. It does not seem working for me.
Any idea on this?

Enthought Canopy --- error in using sklearn

I just installed Enthought Canopy on an Imac Os 10.6.8.
I get an error message (appended below) when I try to test sklearn.
The error is ImportError: numpy.core.multiarray failed to import.
It looks like the wrong version of numpy is being used. I'm not sure how to fix.
Rich
mu51220:~ rscherl$ python
Enthought Canopy Python 2.7.3 | 32-bit | (default, Jun 14 2013, 18:24:40)
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
from sklearn import datasets
/Library/Python/2.6/site-packages/numpy/random/init.py:87: RuntimeWarning: compiletime version 2.6 of module 'mtrand' does not match runtime version 2.7
from mtrand import *
RuntimeError: module compiled against API version 7 but this version of numpy is 6
Traceback (most recent call last):
File "", line 1, in
File "/Users/rscherl/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/sklearn/init.py", line 32, in
from .base import clone
File "/Users/rscherl/Library/Enthought/Canopy_32bit/User/lib/python2.7/site-packages/sklearn/base.py", line 10, in
from scipy import sparse
File "/Users/rscherl/Library/Enthought/Canopy_32bit/System/lib/python2.7/site-packages/scipy/sparse/init.py", line 182, in
from .csr import *
File "/Users/rscherl/Library/Enthought/Canopy_32bit/System/lib/python2.7/site-packages/scipy/sparse/csr.py", line 15, in
from .sparsetools import csr_tocsc, csr_tobsr, csr_count_blocks, \
File "/Users/rscherl/Library/Enthought/Canopy_32bit/System/lib/python2.7/site-packages/scipy/sparse/sparsetools/init.py", line 5, in
from .csr import *
File "/Users/rscherl/Library/Enthought/Canopy_32bit/System/lib/python2.7/site-packages/scipy/sparse/sparsetools/csr.py", line 26, in
_csr = swig_import_helper()
File "/Users/rscherl/Library/Enthought/Canopy_32bit/System/lib/python2.7/site-packages/scipy/sparse/sparsetools/csr.py", line 22, in swig_import_helper
_mod = imp.load_module('_csr', fp, pathname, description)
ImportError: numpy.core.multiarray failed to import
I discovered that I had in my PYTHONPATH (as defined in my .profile)
/Library/Python/2.6/site-packages from where the wrong version of numpy was being picked up.
Eliminating this corrected the problem.

C++ template working fine for GCC but showing compile time error in LLVM-GCC compiler

typedef char TCHAR;
template <class T> class MyTemplateString
{
};
template <class T> class MyList
{
};
typedef MyTemplateString<TCHAR> MyString;
MyList<MyString> outlist;// here it's showing compile time error
The error is:
Implicit instantiation of undefined template MyList <MyTemplateString<char>>
Works fine with GCC compiler only but does not work in LLVM-GCC compiler.
The code as posted above compiles fine here without any errors or warnings using both g++ and llvm-g++:
$ g++ -Wall -c template.cpp
$ llvm-g++ -Wall -c template.cpp
Version info:
$ g++ -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/gcc/gcc-5666.3~123/src/configure --disable-checking --enable-werror --prefix=/usr --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5666) (dot 3)
$ llvm-g++ -v
Using built-in specs.
Target: i686-apple-darwin10
Configured with: /var/tmp/llvmgcc42/llvmgcc42-2335.9~9/src/configure --disable-checking --enable-werror --prefix=/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin10 --enable-llvm=/var/tmp/llvmgcc42/llvmgcc42-2335.9~9/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin10- --host=x86_64-apple-darwin10 --target=i686-apple-darwin10 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.9)
My guess is that your real problem lies elsewhere.

building odcctools in a 64-bit OS

The odcctools package provides binutils for the Darwin OS. -- this allows you to cross compile to Darwin and OSX for example. However, odcctools does not seem to build properly on 64-bit OSes:
./../expr.c: In function ‘expression’:
./../expr.c:311: error: ‘union <anonymous>’ has no member named ‘n_name’
Or, if you set CFLAGS to -m32, you get this:
/usr/bin/ld: skipping incompatible ../libstuff/libstuff.a when searching for -lstuff
/usr/bin/ld: cannot find -lstuff
How do you build this on a 64-bit OS?
The way the odcctools makeflags are set up, you can't use CFLAGS -- you have to set both CC and CXX:
CC="gcc -m32" CXX="g++ -m32" ./configure blah blah blah
Note that I had to add a -fpermissive to my CXX to get it to run but this may not be necessary!
Also, you may be interested in this post (although it wasn't sufficient for my setup).
(If anyone has a better way to do this please let me know!)