New release to include newer dependencies and works for `GCC-14.2`

[sassy-crick]

Hello!

I am part of the EasyBuild community and I am currently trying to build xtb using the foss/2025a toolchain. That is, in short:
gcc-14.2, OpenMPI-5.0.7, FlexiBLAS-3.4.5, FFTW-3.3.10 and ScaLAPACK-2.2.2.
However, trying to use the latest release, version 6.7.1 fails to build with all sorts of errors, some of which are mentioned in this issue: 1329

So I used the GitHub branch instead. That kinda works but there are still a few things which I find odd:

• dftd4: version 3.5.0 seems to be pinned whereas 4.0.0 seems to be the latest
• multicharge: version 0.2.0 seems to be pinned, 0.3.1 seems to work and the latest is 0.5.0
• s-dftd3: version 1.0.0 seems to be pinned but 1.2.1 is the latest.

Now, dft4-4.0.0 cannot be build with multicharge-3.1.0, so I am stuck with dft4-3.7.0 which works with multicharge-0.3.1. Thus, we are stuck with an older version of dft4 which requires an even older version of multicharge (latest is 0.5.1). This seems to be a bit strange to me.

There is also the still open issue of the tblite version: 1345
There is also this issue still open: 1317

With this in mind there are a few question:

• any plans to update the pinned versions to the latest one and thus get newer features?
• any plans to support more modern versions of the GCC compiler?
• any plans for the next release? The latest one is from 2024

Please let me know so I can get back to the user who requested the latest versions of CENSO and CREST.

Thanks!

[foxtran]

any plans to update the pinned versions to the latest one and thus get newer features?

See #1120

any plans to support more modern versions of the GCC compiler?

latest commits works fine with GCC 15.2 on my Intel Mac. On ARM Macs it also should work. So, feel free to use latest compilers.

[foxtran]

BTW, it make sense to use Intel SDK on x86-64 since it gives better performance in comparison with GCC.

[sassy-crick]

@foxtran Thanks again for your response, much appreciated.

See #1120

In the EasyBuild community we are usually using releases, not commits, which is the reason why I was asking for the release specifically. :-)

latest commits works fine with GCC 15.2 on my Intel Mac. On ARM Macs it also should work. So, feel free to use latest compilers.

That also would require to have all the dependencies build with that GCC version and again, I am asking for a release here so I know it all has been checked.

BTW, it make sense to use Intel SDK on x86-64 since it gives better performance in comparison with GCC.

That would only work in a stand-alone scenario but not when you are using other software, like for example ORCA at the same time as ORCA for example requires OpenMPI and thus cannot be use with IntelMPI being loaded at the same time. Besides, I see less demand for the Intel build software right now and my peers are finding the same.

Frankly: looking at the various issues I have raised in the last few months, I noticed a bit of lack of movement here, in particular the involvement of other maintainers. I find that frankly a bit disappointing. Unless the above issue is solved, I will not be able to install xtb or any other depending software like for example CENSO or CREST on our facilities, which is a shame.

[foxtran]

In the EasyBuild community we are usually using releases, not commits, which is the reason why I was asking for the release specifically. :-)

Well... I just marked the issue that raises a problem of dependency inconsistency between different deps of xtb. So, the better approach is to provide something like dependabot to check that dependencies have proper versions, and, once release come to us, we will be sure that it xtb will be able to be compiled without any problem in long days, not just like now that we need to patch build scripts to pin specific versions (and fix minor bugs in source code).

Also, as far as I remember, you can patch software for easier building in EasyBuild. So, it should not be a big problem.

That also would require to have all the dependencies build with that GCC version and again, I am asking for a release here so I know it all has been checked.

Just fork and make release for yourself. It is also a way. Or call it xtb-bleed-<date or commit hash>. I'm using second approach for LLVM with modules and it works nicely almost half of year.

That would only work in a stand-alone scenario but not when you are using other software, like for example ORCA at the same time as ORCA for example requires OpenMPI and thus cannot be use with IntelMPI being loaded at the same time. Besides, I see less demand for the Intel build software right now and my peers are finding the same.

xtb does not require MPI. Not sure that it is possible to avoid loading of IntelMPI in EasyBuild. At least for modules it works. Anyway, you can provide static build of xtb for end-users, so they will be able to mix Intel-compiled xtb and GCC/LLVM/Oracle/whatever shared-compiled software.

I noticed a bit of lack of movement here, in particular the involvement of other maintainers.

Feel free to become a maintainer.

[boegel]

That also would require to have all the dependencies build with that GCC version and again, I am asking for a release here so I know it all has been checked.

Just fork and make release for yourself. It is also a way. Or call it xtb-bleed-<date or commit hash>. I'm using second approach for LLVM with modules and it works nicely almost half of year.

EasyBuild lead developer here.

First of all, thanks a lot for the feedback @foxtran! Much appreciated.

The reason we strongly prefer to stick to proper releases of software is that those are considered "vetted" by the software developers. We often lack domain expertise to know when a codebase is sufficiently "mature" to be considered stable. So forking doesn't make much sense for us...

That said, we can definitely just use the latest commit and slap a version like 6.7.1-20251123 (so version in code + datestamp) on it. Seems like that will be a necessary evil for xtb for the time being.

We're doing what we can to get complex software projects like xtb in the hands of researchers, and making them easy to use.