-
Notifications
You must be signed in to change notification settings - Fork 448
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Arguments of dsyevx, dgeevx changed and now the treekin package is broken #604
Comments
What changed is the (addition of a) definition of LAPACK_FORTRAN_STRLEN_END in lapack.h for when you call LAPACK functions directly from your C code, instead of through LAPACKE. This was added to expose the hidden/implied string length arguments that most/all Fortran compilers expect to be present, as Fortran does not use NULL-termination of strings like C does. |
(I do wonder what this means for compatibility with both past and alternative implementations (MKL?), and why it was not mentioned in the release notes for 3.10.0) |
I wonder who is going to be fixing software that used these functions (ex. treekin) which doesn't have active devs now. |
Legacy functions should be left in the library for the older software to use. |
Hi. The old interface should still work if you remove these lines: lapack/LAPACKE/include/lapack.h Lines 16 to 19 in 3b26987
Did you (Could you please) try it? |
This seems to require lapack to be rebuilt with these lines removed. Other packages need to use the pre-built lapack package, one for all. |
I'm not sure you need to rebuild LAPACK only because of those lines. We only use |
Having to modify a "system/distribution preinstalled" header depending on whose source you want to compile against LAPACK is not ideal either, I wonder if it would be possible to create a truly variadic prototype that would match both "traditional" and "pedantic" use ? |
This line:
breaks with:
and this line
breaks with
Any idea how to patch them? |
You'd need to add an "int" after the "info" parameter for each "char*" argument in the list. But I am not sure how portable that is with respect to earlier or alternative implementations of LAPACK: |
This depends on the compiler and in the case of gfortran also on the gfortran version! The GNU Fortran Compiler 11.2.0 Documentation: Argument passing conventions:
gfortran 7 expected a hidden |
So what's the best solution for the many C/C++ projects out there that expect the old API without the trailing string lengths? |
Yes, the best solution, in my opinion, is to use LAPACKE. If there are issues with LAPACKE, let us know. LAPACKE should work for great for C and C++. If you are working in C++ and you want a wrapper to LAPACK, you might want to have a look at LAPACK++ which is a C++ interface to LAPACK (that uses LAPACKE). |
The treekin port was fixed by patching:
|
@yurivict I suspect you can make it compatible with both old and new if you check if LAPACK_FORTRAN_STRLEN_END is defined (sits in lapack.h which gets included by lapacke.h) - at least as long as you can be sure that the lapacke.h came with the flavor of LAPACK library that you are linking against. (BTW not sure what the (truncated?) first chunk of the diff is about). |
Recently there were some changes to these functions and now the
biology/treekin
port breaks:https://www.tbi.univie.ac.at/RNA/Treekin/
I am the maintainer of the FreeBSD port but I have no idea how to fix it now.
Were these functions changed intentionally or accidentally?
lapack-3.10.0
The text was updated successfully, but these errors were encountered: