-
Notifications
You must be signed in to change notification settings - Fork 369
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
Not possible to link Blis and Lapack statically into the same executable #816
Comments
We also just handled a similar request via #812. Your request, @tbetcke, has me wondering about a general-purpose solution that combines the compatibility accommodations for both 812 and your request into a single option, say, What do you think, @devinamatthews? |
Yes, that's an interesting idea but it would be a lot of work to make it work "seamlessly" for end-users (e.g. they can disable any symbols within certain classes), and would be surprising to users if the list of symbols which can be disabled is small, irregularly defined, and/or constantly changing. |
As an author of applications that use BLIS, LAPACK, and ScaLAPACK together, I'm generally in favor of improving interoperability. Beyond resolving multiply defined symbols, what I'd really like is for BLIS implementations to override those in Sca/LAPACK. A partial solution would be for BLIS to name-mangle select routines with |
I think the point Nick is making: the implementation in a BLAS library is likely to be higher performing than the reference implementation in LAPACK or ScaLAPACK (or some other library). Hence, it is such a library that should selectively remove rather than, say, BLIS. On the other hand, XERBLAS may be a replacement for the one in the BLAS specifically to do more meaningful error handling. In that case, it is the one in LAPACK/ScaLAPACK that should overwrite. This is, I guess, an argument for vertical integration of such libraries... A project we intend to pursue next. |
For the computational routines, one can access the BLIS version using the BLIS object or typed APIs. For stuff like |
Is it possible to mitigate the problem with |
@tbetcke does linking with |
@tbetcke one thing that we are concerned about in particular is I am told the most recent version of LAPACK marks |
Or, we could add an |
Apologies the long absence from this discussion. @devinamatthews would something like Openblas work in principle, where one can build Lapack as part of OpenBLAS? This would solve the multiple libraries issue for static archives as well. |
I'm currently implementing the following
Did I miss any of the symbols germane to this or related Issues? |
Details: - Added a new option to 'configure' that allows the user to specify a list of symbols to omit from the library. The format of the option is --omit-symbols=LIST where LIST is a comma-separated list of symbol names (excluding any trailing underscore). This list is parsed into a list of #define directives that causes the relevant parts of BLIS to be ignored (or not). As such, the nature of this option is to only support omitting symbols which have been pre-identified as potential troublemakers when linking BLIS with other libraries such as LAPACK or ScaLAPACK. (This list may grow in the future as additional symbols are identified.) - Re-implemented the --enable-scalapack-compat configure option to utilize the underlying --omit-symbols=LIST infrastructure. - Implemented an --enable-lapack-compat option, which omits all of the known problematic symbols currently supported for omission. - This commit addresses Issue #816. Thanks to Timo Betcke for bringing it to our attention and to Devin Matthews for his advice and for his initial implementation of --enable-scalapack-compat (PR #813). - CREDITS file update.
Details: - Added a new option to 'configure' that allows the user to specify a list of symbols to omit from the library. The format of the option is --omit-symbols=LIST where LIST is a comma-separated list of symbol names (excluding any trailing underscore). This list is parsed into a list of #define directives that causes the relevant parts of BLIS to be ignored (or not). As such, the nature of this option is to only support omitting symbols which have been pre-identified as potential troublemakers when linking BLIS with other libraries such as LAPACK or ScaLAPACK. (This list may grow in the future as additional symbols are identified.) Note: we leave lsame_() and xerbla_() prototypes enabled even when their respective symbols are omitted from the library. - Re-implemented the --enable-scalapack-compat configure option to utilize the underlying --omit-symbols=LIST infrastructure. - Implemented an --enable-lapack-compat option, which omits all of the known problematic symbols currently supported for omission. - This commit addresses Issue #816. Thanks to Timo Betcke for bringing it to our attention and to Devin Matthews for his advice and for his initial implementation of --enable-scalapack-compat (PR #813). - CREDITS file update.
I would like to link Blis and Lapack statically into the same executable. However, this is not possible since several symbols are multiply defined between Blis and Lapack. These are
lsame
,xerbla
,xerbla_array
,crot
,czymv
,csyr
,zrot
,zsymv
,zsyr
.I noticed an earlier bug report #776 in which some of these were discussed and then included into Blis. Would it be possible to have an option to disable this in the future?
The background is that I am integrating them into a Rust project. Rust prefers static linkage and does not handle rpath well for shared libraries.
The text was updated successfully, but these errors were encountered: