OpenBLAS with ILP64 using conda appends a _ at the end of the library name

[JorgeG94]

Feel free to close this if not relevant to the main openblas repo. When I install openblas via conda using: conda install conda-forge::openblas-ilp64 it installs perfectly but the library name is libopenblas64_.a which makes the native find_package(BLAS) fail because it specifically looks for libopenblas64.a

I can change the behaviour of my CMake to account for this but it would be ideal if it is not too big of a deal to also create libopenblas64.a

Thanks in advance :)

[martin-frbg]

Dumb question - which OpenBLAS version does this install, and is that a source or binary install ?

[JorgeG94]

Dumb question - which OpenBLAS version does this install, and is that a source or binary install ?

I am a conda novice so bear with me...it installs 0.3.29

https://anaconda.org/anaconda/openblas

and I believe it does a binary install, it is too quick to have built from source.

[martin-frbg]

We've been through a round of bugs with library naming after I tried to integrate new options for pre- and postfixing both default function and library names. But I think having a trailing underscore on the library name must be due to some unfortunate choice of build option rather than a wrong default in the build files @h-vetinari ?

[h-vetinari]

I cannot speak for the packages from the official Anaconda channels, I only help take care of the conda-forge side (built here, artefacts here).

The whole LP/ILP integer model handling is of course a major PITA (thank C89 for making wobbly-sized integers the default). In conda-forge, we simply pass SYMBOLSUFFIX="64_" to openblas' makefile (the trailing _ is due to some old Fortran compiler conventions AFAIU, see Reference-LAPACK/lapack#666).

We could presumably patch the way that openblas creates the library name from the SYMBOLSUFFIX (or openblas could do it themselves), but IMO this sounds more like a problem of the expectations of CMake's find_package to me. If openblas were built with CMake, then we wouldn't have these problems of course (assuming use of CONFIG to actually use the installed metadata and not built-in CMake routines).

You can check out here how the sausage is made. If you have some improvements to suggest, feel free to open a PR (or an issue with a fully filled issue template). For the anaconda channels, the recipe is elsewhere.

[JorgeG94]

I cannot speak for the packages from the official Anaconda channels, I only help take care of the conda-forge side (built here, artefacts here).

The whole LP/ILP integer model handling is of course a major PITA (thank C89 for making wobbly-sized integers the default). In conda-forge, we simply pass SYMBOLSUFFIX="64_" to openblas' makefile (the trailing _ is due to some old Fortran compiler conventions AFAIU, see Reference-LAPACK/lapack#666).

We could presumably patch the way that openblas creates the library name from the SYMBOLSUFFIX (or openblas could do it themselves), but IMO this sounds more like a problem of the expectations of CMake's find_package to me. If openblas were built with CMake, then we wouldn't have these problems of course (assuming use of CONFIG to actually use the installed metadata and not built-in CMake routines).

You can check out here how the sausage is made. If you have some improvements to suggest, feel free to open a PR (or an issue with a fully filled issue template). For the anaconda channels, the recipe is elsewhere.

hmmm.... yeah from the issue you posted it seems that the 64_ is needed because of how Julia interfaces to the blas libraries and needing to take care of that. It is quite annoying that it breaks the standard CMake search for it. This sounds like I will be directing my efforts to contributing to CMake to account for 64_ in addition to 64.a/so. Since I do agree with you this problem is with CMake not OpenBLAS. Thanks for the clarification and very very quick turnaround on your comments.

Keep up the good work!