Skip to content
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

Open
tbetcke opened this issue Jun 25, 2024 · 12 comments
Open

Comments

@tbetcke
Copy link

tbetcke commented Jun 25, 2024

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.

@fgvanzee
Copy link
Member

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, --disable-symbols=<comma-separated-list-of-symbols>. Then the user could omit whichever symbols they wish. (Of course, we'd have to guard the eligible symbols with cpp macros, but that's not difficult and it's something we can do incrementally as these offending symbols are brought to our attention.)

What do you think, @devinamatthews?

@devinamatthews
Copy link
Member

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.

@nick-knight
Copy link

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 __wrap_, so I can use --wrap to prefer BLIS implementations. I believe that this solution is only partial because I don't see how it could hijack the libcalls inside the Sca/LAPACK binaries; achieving that I think would require build-system modifications in both BLIS and Sca/LAPACK. I don't know the best way forward to request such cross-project functionality.

@rvdg
Copy link
Collaborator

rvdg commented Jun 27, 2024

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.

@devinamatthews
Copy link
Member

For the computational routines, one can access the BLIS version using the BLIS object or typed APIs. For stuff like lsame and xerbla there is no really good solution (esp. for xerbla since that is supposed to be overridden by user applications.

@leekillough
Copy link
Collaborator

Is it possible to mitigate the problem with __attribute__((weak))?

@devinamatthews
Copy link
Member

@tbetcke does linking with -Wl,-z,muldefs work?

@devinamatthews
Copy link
Member

@tbetcke one thing that we are concerned about in particular is xerbla. Is a custom version of xerbla (not the one in BLIS or LAPACK) also being included? The "default" xerbla may exit on error which I assume is not what you want in a Rust crate.

I am told the most recent version of LAPACK marks xerbla as a weak symbol so we could do that too, also for lsame and xerbla_array. For the computational routines (crot etc.), we'll make sure these are covered by --enable-scalapack-compat.

@devinamatthews
Copy link
Member

Or, we could add an --enable-lapack-compat for the other symbols.

@tbetcke
Copy link
Author

tbetcke commented Jul 13, 2024

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.

@fgvanzee
Copy link
Member

I'm currently implementing the following configure option:

   --omit-symbols=LIST

                 Omit a custom set of compatibility symbols when building
                 BLIS. When given, LIST is parsed as a comma-separated
                 list of symbol names (excluding any trailing underscore).
                 This option is useful when (1) the user is planning to
                 link BLIS with another library that provides conflicting
                 symbols, and (2) the user wishes the symbols in this
                 other library to prevail at link time without relying on
                 weak/strong symbol semantics. Note that currently only
                 the following symbols are supported for omission:

                           crot    zrot    lsame
                           csymv   zsymv   xerbla
                           csyr    zsyr    xerbla_array
                           csyr2   zsyr2

Did I miss any of the symbols germane to this or related Issues?

fgvanzee added a commit that referenced this issue Aug 1, 2024
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.
@fgvanzee
Copy link
Member

fgvanzee commented Aug 8, 2024

@tbetcke FYI, I implemented --omit-symbols=LIST in #823 (and reimplemented --enable-scalapck-compat, and added --enable-lapack-compat). Please give it a try when you have the time. Thanks so much.

fgvanzee added a commit that referenced this issue Oct 16, 2024
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants