[openblas] Make build_lapack=True default for >= 0.3.21

[samuel-emrys]

Version 0.3.21 of openblas introduced the ability to build lapack from C. Make this default to enable CCI recipes to use lapack when depending on openblas.

Additionally, fix an inconsistency in version constraint. Review was provided in #19808 to constrain it to 0.3.24 as this was the latest version available in CCI. However, functionality to build lapack was added in 0.3.21, so it doesn't really make sense to exclude versions between 0.3.21 and 0.3.24 from building lapack should they be added at a later date.

Closes #7361

Specify library name and version: openblas/0.3.24

---

• I've read the contributing guidelines.
• I've used a recent Conan client version close to the currently deployed.
• I've tried at least one configuration locally with the conan-center hook activated.

[ghost]

I detected other pull requests that are modifying openblas/all recipe:

• openblas: add v0.3.25 #21661
• openblas: improve cross compilation support #21485
• openblas: Improve recipe plus conan v2 #17173

This message is automatically generated by https://github.com/ericLemanissier/conan-center-conflicting-prs so don't hesitate to report issues/improvements there.

[samuel-emrys]

@uilianries any idea what's going on with CI here?

[uilianries]

Version 0.3.21 of openblas introduced the ability to build lapack from C. Make this default to enable CCI recipes to use lapack when depending on openblas.

@samuel-emrys Could you please, show a link or document proving that support, just in case?

[samuel-emrys]

@samuel-emrys Could you please, show a link or document proving that support, just in case?

@uilianries this PR only makes the lapack build default. Support for building lapack from C was approved by yourself in #19808:

Okay, it seems be following https://github.com/OpenMathLib/OpenBLAS/releases/tag/v0.3.21

From the v0.3.21 release notes:

when no Fortran compiler is available, OpenBLAS builds will now automatically
build LAPACK from an f2c-converted copy of LAPACK 3.9.0 unless the NO_LAPACK option
is specified (more recent releases make too heavy use of Fortran90+ features to be easily convertible to C)

[uilianries]

I'm not confident accepting this PR now, because there is no fortran support when building this package in CCI:

https://c3i.jfrog.io/c3i/misc/logs/pr/20894/3-linux-gcc/openblas/0.3.24//729e2486182de25560f46a58cc644fb2e1eb8b2f-build.txt

The version 0.3.24 will build with lapack, but no fortran is available, so the generated package is not good, someone will open an issue complaining about this lack of support for sure.

I'll check with Conan team to include fortran to Linux docker images, at least, we could solve it partially.

[samuel-emrys]

I'm not confident accepting this PR now, because there is no fortran support when building this package in CCI:

https://c3i.jfrog.io/c3i/misc/logs/pr/20894/3-linux-gcc/openblas/0.3.24//729e2486182de25560f46a58cc644fb2e1eb8b2f-build.txt

The version 0.3.24 will build with lapack, but no fortran is available, so the generated package is not good, someone will open an issue complaining about this lack of support for sure.

@uilianries I'm not sure I follow what you mean. What are you drawing attention to in those logs? All that related to fortran that I could find was this:

openblas/0.3.24: Building LAPACK without Fortran compiler

which is the point of this PR. We can remove any dependency on fortran by building lapack from C sources. I'm not sure why anybody would complain, as it's reasonably easy to trigger a fortran build by defining the fortran key in compiler_executables if desired as per

conan-center-index/recipes/openblas/all/conanfile.py

Lines 40 to 44 in e354330

	def _fortran_compiler(self):
	comp_exe = self.conf.get("tools.build:compiler_executables")
	if comp_exe and 'fortran' in comp_exe:
	return comp_exe["fortran"]
	return None

I'll check with Conan team to include fortran to Linux docker images, at least, we could solve it partially.

#19808 removed the dependence on fortran so that we can build lapack with a C++ only toolchain - this seems to be the most desirable solution to me - what am I missing? -lgfortran is only added when the user specifies a value for compiler_executables={"fortran": "/path/to/gfortran"}, which would not be default for openblas >= 0.3.21 since this is not included in the conan profiles.

Lack of lapack support on CCI due to lack of a fortran compiler has been an ongoing issue for years now (#5260, #15556). I would really rather solve this with the simplest solution we have which is to build it from C. It's not perfect - it version locks lapack to 3.9.0, but it gives CCI minimum viability uniformly across all operating systems. Other math packages only provide limited utility without lapack, such as armadillo.

If we can explore adding fortran compilers to conan CI infrastructure to add a proper lapack recipe or build it here, that would be good as well, but I strongly suggest we should go for the quick win here.

[samuel-emrys]

@uilianries can you engage on this more/elaborate on your reasoning? it doesn't make a lot of sense to me and having lapack available is a critical requirement for math libraries in CCI.

cc @RubenRBS @memsharded

[uilianries]

@samuel-emrys indeed is a problem also related to the CI. I'll take a look to provide fortran via Docker images, so it should be able to build anything. Some images are prepared already (conanio/gcc11-ubuntu16.04), but Clang images need and extra build (checking to use llvm flang). For legacy images will be more complicated, because some of them are using ubuntu-toolchain-r or llvm repository and fortran is not always available.

[samuel-emrys]

@uilianries understood, but this is a conversation we've been having for approx 2 years.. I'm not sure I understand the issue you have with the above solution of removing any Fortran requirement from building lapack in openblas - can you elaborate on that?

[samuel-emrys]

Adding fortran support to conan ci's is a good idea and is something that should be progressed independently of this PR, but it does open a can of worms with respect to binary compatibility - conan doesn't currently have a way to describe the ABI or runtime requirements that building a package with ifort or gfortran implies.

Building the fortran components from sources that have been converted to C really is the best way forward here in my opinion, because none of those ABI considerations will factor in here - it becomes a plain C library.

This is what we want as default wherever possible until conan has the features to support polyglot considerations.

[samuel-emrys]

@uilianries @RubenRBS what's the best way to have a conversation about this and/or an alternate pathway to getting lapack/other fortran libs on cci? Here or slack? I don't understand the rationale for not accepting this - this seems to be the best solution for conan because it bypasses the fortran requirement entirely, and this has been an ongoing issue for years (#5260, #15556) - getting a resolution here would be good and would enable a number of scientific computing libraries to work unimpeded.

// cc @memsharded

[samuel-emrys]

Just to be clear in case it was missed above, the reason I'm confused is that from the release notes:

when no Fortran compiler is available, OpenBLAS builds will now automatically
build LAPACK from an f2c-converted copy of LAPACK 3.9.0 unless the NO_LAPACK option
is specified (more recent releases make too heavy use of Fortran90+ features to be easily convertible to C)

This means that the sources have been converted from fortran to c, so this change triggers a build from the C sources only by default, meaning that there's no dependency on fortran at all here - this is essentially a C library, which sidesteps the problem of using fortran at all. I would imagine is the easiest path forward for conan-center-index.

[samuel-emrys]

These failures are as a result of d34e4a1, which introduces a native Macos armv8 runner to the c3i build matrix. armv8 builds of openblas have to date, only been explicitly disallowed for cross builds, and so an "invalid" configuration has made it through here and is causing failures.

I've attempted to add armv8 compatibility in this PR (by hotfixing OpenMathLib/OpenBLAS#4142
), but if this doesn't work, I'll exclude native armv8 builds from the valid build matrix and leave the improvement for a future PR.

This also relates to #21485

[conan-center-bot]

Conan v1 pipeline ✔️

All green in build 12 (5fc291028587a9336864cf80c11d819ec6607db3):

• openblas/0.3.25:
  All packages built successfully! (All logs)

• openblas/0.3.10:
  All packages built successfully! (All logs)

• openblas/0.3.24:
  All packages built successfully! (All logs)

• openblas/0.3.17:
  All packages built successfully! (All logs)

• openblas/0.3.15:
  All packages built successfully! (All logs)

• openblas/0.3.13:
  All packages built successfully! (All logs)

• openblas/0.3.20:
  All packages built successfully! (All logs)

• openblas/0.3.12:
  All packages built successfully! (All logs)

---

Conan v2 pipeline ✔️

Note: Conan v2 builds are now mandatory. Please read our discussion about it.

All green in build 12 (5fc291028587a9336864cf80c11d819ec6607db3):

• openblas/0.3.25:
  All packages built successfully! (All logs)

• openblas/0.3.24:
  All packages built successfully! (All logs)

• openblas/0.3.17:
  All packages built successfully! (All logs)

• openblas/0.3.20:
  All packages built successfully! (All logs)

• openblas/0.3.15:
  All packages built successfully! (All logs)

• openblas/0.3.12:
  All packages built successfully! (All logs)

• openblas/0.3.10:
  All packages built successfully! (All logs)

• openblas/0.3.13:
  All packages built successfully! (All logs)

[samuel-emrys]

I've reverted the changes to add armv8 compatibility as they weren't immediately working (and they're beyond the scope of this PR), and I've added an additional exclusion for armv8 to the validate() method to reflect the current incompatibility. This can be followed up in #21485 which aims to add this compatibility.

[uilianries]

LGTM