I'm trying to support zgetrf() in both Ubuntu 18.04 and CentOS 7 by using dlopen() against the .so and opening the function in each version, but the calling convention is different. In CentOS it works using LAPACKE_zgetrf() but in Ubuntu 18.04 they do not export as LAPACKE_zgetrf, the only option is zgetrf_:
# objdump -T /usr/lib/i386-linux-gnu/libopenblas.so.0 |grep zgetrf
[...]
000c3a60 g DF .text 00000191 Base zgetrf_
I can make an LAPACKE_zgetrf() call as follows, this works:
LAPACKE_zgetrf(order, m, n, a, ndim, (int32_t*)ip);
How do I convert it to call zgetrf_(...) ?
The LAPACKE_ functions will call the linked openblas.so.0 library, so no need to link to openblas.so.0 directly.
For ATLAS, you can call the clapack_ functions exported by liblapack_atlas.so.3 which are nearly the same format (same order, same type) except that the transform argument is different. For example, in zgetrs() in ATLAS might take the standard BLAS CblasTrans enum for the transform argument. However, in OpenBLAS (and MKL) this argument should be converted from ATLAS to OpenBLAS as follows:
openblas_trans = ((trans) == CblasConjTrans ? 'C' : ((trans) == CblasTrans ? 'T' : 'N'))
Related
I'm trying to run a SQL query in my Firebird database. I've restored a backup in my local development environment.
My error is the following:
echo "SELECT STRTOINT('3') FROM MyTable;" | isql-fb /var/lib/firebird/3.0/data/dbname.fdb
Statement failed, SQLSTATE = 39000
invalid request BLR at offset 36
-function STRTOINT is not defined
-module name or entrypoint could not be found
To check if the function exists i run this:
echo 'SELECT RDB$FUNCTION_NAME FROM RDB$FUNCTIONS;' | isql-fb /var/lib/firebird/3.0/data/dbname.fdb | grep STRTOINT
STRTOINT
How to call the function correctly? Any hints are welcome!
The fact that the UDF is defined in the database does not mean the UDF exists. UDFs require both a definition in the database, and a native library (.dll/.so) on disk that contains the code for the UDF function.
The error means that either
The UDF does not exist in any of the libraries found,
Firebird has no permission to read the library,
The folder containing the library is not defined in firebird.conf (setting UdfAccess)
The UDF library is 32 bit and Firebird is 64 bit (or vice versa)
See also invalid request BLR at offset 163
Firebird itself has no UDF called STRTOINT, so you need to find out which third-party library this is, and install it correctly.
Have you tried to do the following?
CAST(MyVarcharCol AS INT)
Read more: http://www.firebirdfaq.org/faq139/
With Matlab R2015b on 32-bit Windows 7, LOADLIBRARY was working fine:
library = 'C:\Windows\System32\visa32.dll';
headerFile = 'C:\Program Files\IVI Foundation\VISA\WinNT\include\visa_Matlab.h';
loadlibrary(library, headerFile, 'alias','visa32');
and I can use functions in 'visa32.dll', such as,
defaultRm = 0;
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
vi = 0;
InstrAddr = 'GPIB0::29::INSTR';
pInstrAddr = libpointer('int8Ptr', [int8( InstrAddr ) 0] );
[err, tempVar, vi] = calllib('visa32', 'viOpen', defaultRm, pInstrAddr, 0, 0, vi);
to open instrument's communication port...
But after I have upgraded to 64-bit Windows 7 and Matlab R2017b, LOADLIBRARY won't work any more, even I have use 62-bit versions of 'visa32.dll' and 'visa.h'. There are two problems:
(1) Firstly, Matlab complaints about not have the right compiler installed and can't even run LOADLIBRAY. Follow their online instruction to install the MinGW-w64 Compiler addon. This problem seems to have revolved.
(2) LOADLIBRAY seems to be able to run, but then it has the following error:
Failed to parse type '( fastcall )) viOpenDefaultRM ( ViPSession vi' original input '( fastcall )) viOpenDefaultRM ( ViPSession vi '
Found on line 217 of input from line 93 of file C:\Program Files (x86)\IVI Foundation\VISA\WinNT\Include\visa.h
Error parsing argument for function attribute function may be invalid.
...
I wonder if somebody could help please. Many thanks in advance!
The advantages of using VISA library in MATLAB for instrument control are: direct (i.e. faster) access to ports, be able to use GTL (go-to-local) and handles communication error better, etc. Use LOADLIBRARY to load the VISA library and CALLLIB to access the functions in the loaded library, e.g.
loadlibrary('visa32.dll','visa.h','alias','visa32');
[err, defaultRm] = calllib('visa32', 'viOpenDefaultRM', defaultRm);
However, limitations in LOADLIBRARY have caused a lot of trouble, and it works differently for different Windows architecture. Here is the solution that has been tested on 32- and 64-bit Windows:
1. C++ compiler in MATLAB:
a. This only affects 64-bit MATLAB;
b. A MATLAB add-on called ‘MinGW-w64 Compiler’ must be installed:
i. this is relatively easy for R2017b, just use MATLAB’s Add-Ons Manager;
ii. for MATLAB version prior to R2017b, it is very difficult:
Download and install 'MinGW-w64' from:
tdm-gcc.tdragon.net/download
sourceforge.net/projects/tdm-gcc/postdownload?source=dlp
sourceforge.net/projects/mingw/files/
Then configure MATLAB as described in:
de.mathworks.com/help/matlab/matlab_external/compiling-c-mex-files-with-mingw.html
de.mathworks.com/help/matlab/matlab_external/install-mingw-support-package.html
de.mathworks.com/matlabcentral/answers/313298-i-already-have-mingw-on-my-computer-how-do-i-configure-it-to-work-with-matlab
2. VISA library file:
a. Different DLL file for different Windows architecture;
b. The library file is available after the installation of NI-488.2 driver (the latest version to date is 'NI4882_1760f0.exe';
c. For 32-bit Windows and 32-bit MATLAB:
i. Library file: ‘visa32.dll’
ii. Location: ‘C:\Windows\System32\’
d. For 64-bit Windows and 64-bit MATLAB:
i. Library file: ‘visa64.dll’
ii. Location: ‘C:\Windows\System32\’
iii. Notes:
1. According to NI’s website, the 64-bit VISA DLL is ‘visa32.dll’ that resides in 'C:\Windows\SysWOW64. This is not right;
2. Alternatively, a 64-bit version of ‘visa32.dll’, which is smaller than ‘visa64.dll’ installed by NI-488.2 driver, can be downloaded from: https://www.azdll.net/files/visa32-dll.html.
3. Header files:
a. Two headers files are needed to load the VISA library: ‘visa.h’ and ‘visatype.h’;
b. Both are available after the installation of NI-488.2 driver;
c. For 32-bit Windows, both files are in:
‘C:\Program Files\IVI Foundation\VISA\Win64\include’
d. For 64-bit Windows, both files are in:
‘C:\Program Files (x86)\IVI Foundation\VISA\WinNT\include’
e. ‘visatype.h’ can be used as it is;
f. ‘visa.h’ must be modified for MATLAB’s LOADLIBRARY. Changes made on ‘visa.h’ are:
i. Add the following at the beginning of the header file:
#ifdef _WIN64
#define __fastcall
#endif
ii. Mask out 'viInstallHandler' and 'viUninstallHandler', as they are not commonly used;
iii. Remove ', ...' from the following functions as it’s not supported by LOADLIBRARY (https://de.mathworks.com/matlabcentral/answers/103180-why-do-i-get-warnings-when-loading-a-dll-with-loadlibrary-in-matlab-7-13-r2011b):
viPrintf, viSPrintf, viScanf, viSScanf, viQueryf
iv. Replace 'ViVAList' with 'ViConstBuf' in the following functions:
viVPrintf, viVSPrintf, viVScanf, viVSScanf, viVQueryf
v. Replace the 'viVxiServantResponse' function with the following:
#ifndef _WIN64
ViStatus _VI_FUNC viVxiServantResponse(ViSession vi, ViInt16 mode, ViUInt32 resp);
#endif
g. The modified ‘visa.h’, renamed as ‘visa_Matlab.h’, can be downloaded from visa_Matlab.h.
Example:
% ‘visa32.dl’ or ‘visa64.dll’, ‘visa_Matlab.h’ and ‘visatype.h’ must be
% available in the local directory
archstr = computer('arch');
if ~isempty(strfind(archstr, 'PCWIN64')) || ~isempty(strfind(archstr, 'win64'))
dllName = 'visa64';
else
dllName = 'visa32';
end
headerFileName = 'visa_Matlab.h';
loadlibrary ([dllName '.dll'], 'visa_Matlab.h','alias',dllName);
visaFunctions = libfunctions(dllName,'-full');
Scenario:
Ubuntu 17.04
Liquid Soap 1.1.1 installed by apt-get
Liquid Soap 1.3.1 installed by OPAM
On 1.1.1, I cannot use AAC+ encoder. So I've installed 1.3.1 with AAC+ support. But using a same .liq file, both versions act different.
For some reason, 1.1 works, 1.3 not:
def my_request_function() =
# Get the first line of my external process
result = list.hd(get_process_lines("php -q liquid.php"))
# Create and return a request using this result
request.create(result)
end
Error:
At line 17, char 24:
this value has type
(default:_)->_ (inferred at line 15, char 19-58)
but it should be a subtype of
string
I want to read the "next song" from a PHP script. On 1.1.1 works with MP3 (+icecast2), but since I need AAC+, I'm using 1.3.1, that I cannot figure out how to read the external script.
Any ideas? Thank you.
1.3 had another argument added to list.hd and other list functions.
https://github.com/savonet/liquidsoap/blob/master/CHANGES#L52
You can update your code with the new default value argument and it should work.
result = list.hd(default="", get_process_lines("php -q liquid.php"))
This is very simple to recreate.
If my script foo.py is:
import scipy
Then run:
python pyinstaller.py --onefile foo.py
When I launch foo.exe I get:
WARNING: file already exists but should not: C:\Users\username\AppData\Local\Temp\_MEI86402\Include\pyconfig.h
I've tested a few versions but the latest I've confirmed is 2.1dev-e958e02 running on Win7, Python 2.7.5 (32 bit), Scipy version 0.12.0
I've submitted a ticket with the Pyinstaller folks but haven't heard anything yet. Any clues how to debug this further?
You can hack the spec file to remove the second instance by adding these lines after a=Analysis:
for d in a.datas:
if 'pyconfig' in d[0]:
a.datas.remove(d)
break
The answer by wtobia# worked for me. See https://github.com/pyinstaller/pyinstaller/issues/783
Go to C:\Python27\Lib\site-packages\PyInstaller\build.py
Find the def append(self, tpl): function.
Change if tpl[2] == "BINARY": to if tpl[2] in ["BINARY", "DATA"]:
Expanding upon Ilya's solution, I think this is a little bit more robust solution to modifying the spec file (again place after the a=Analysis... statement).
a.datas = list({tuple(map(str.upper, t)) for t in a.datas})
I only tested this on a small test program (one with a single import and print statement), but it seems to work. a.datas is a list of tuples of strings which contain the pyconfig.h paths. I convert them all to lowercase and then dedup. I actually found that converting all of them all to lowercase was sufficient to get it to work, which suggests to me that pyinstaller does case-sensitive deduping when it should be case-insensitive on Windows. However, I did the deduping myself for good measure.
I realized that the problem is that Windows is case-insensitive and these 2 statements are source directories are "duplicates:
include\pyconfig.h
Include\pyconfig.h
My solution is to manually tweak the .spec file with after the a=Analysis() call:
import platform
if platform.system().find("Windows")>= 0:
a.datas = [i for i in a.datas if i[0].find('Include') < 0]
This worked in my 2 tests.
A more flexible solution would be to check ALL items for case-insensitive collisions.
I ran the archive_viewer.py utility (from PyInstaller) on one of my own --onefile executables that has the same error and found that pyconfig.h is included twice:
(31374007, 6521, 21529, 1, 'x', 'include\\pyconfig.h'),
(31380528, 6521, 21529, 1, 'x', 'Include\\pyconfig.h'),
(31387049, 984, 2102, 1, 'x', 'pytz\\zoneinfo\\CET'),
Sadly though, I don't know how to fix it.
PyInstaller Manual link:
http://www.pyinstaller.org/export/d3398dd79b68901ae1edd761f3fe0f4ff19cfb1a/project/doc/Manual.html#archiveviewer
I am getting an error when i test CBLAS in CLAPACK. When i run the test code
./xblat2d < dblat2.in
I get the error output:
"TransA must be 111, 112 or 113, but is set to -1Parameter 2 to routine cblas_dgemv was incorrect"
Does anyone know what kind of problem this indicates?
Details
I am trying not to use reference CBLAS, and use ATLAS CBLAS instead. So, i compiled wrapper library libcblaswr.a and changed the line in make.inc to
BLASLIB = ../../libcblaswr.a -L/usr/local/atlas/lib -lcblas -L/usr/local/atlas/lib -latlas
CLAPACK installation suggest doing
BLASLIB = ../../libcblaswr.a -lcblas -latlas
But linker doesn't find cblas and atlas without me using -L option, so i included it.
Details of my setup:
Ubunty Lycid Lynx 10.04
CLAPACK-3.2.1
ATLAS.3.9.51
This appears to be a problem with the CLAPACK test in that it passes the wrong parameters to the BLAS routines. In calling dgemv there is an option for the matrix to operate as itself or as the transpose or as the conjugate transpose, corresponding to 111, 112 or 113 (see line 6 of cblas.h). The code in CLAPACK doesn't set the parameter correctly. I haven't looked deep enough to know if this is an issue with just the test or if the issue runs deeper; but I suspect it's just with the test as I haven't run in to this issue using any CLAPACK code.
I have ignored it because 1) I'm not depending on CLAPACK to test the BLAS routines installed by ATLAS and 2) if there's a deeper issue it will cause an error like this rather than produce invalid results, and I'll track it down then.
And yes, the linker won't find -lcblas and -latlas until you install them somewhere normally searched, this is normal.