Not possible to link Blis and Lapack statically into the same executable about blis HOT 12 OPEN

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.

from blis.

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?

from blis.

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.

from blis.

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.

from blis.

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.

from blis.

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

from blis.

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

from blis.

@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.

from blis.

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

from blis.

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.

from blis.

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?

from blis.