Remove zheev, zpotrf as they are in Rlapack, to avoid linking problems.

[kalibera]

The trick with linking first Rlapack and then as a back-up local definitions of some routines doesn't work on Windows with LLVM/lld. The linker, once it sees the symbols in the DLL, expects they would be in a DLL and is confused when it find them somewhere else (the error message is like ''ld.lld: error: zheev_ was replaced").

This simple patch removes zheev and zpotrf from the local backup library, as these are already present in Rlapack and have been for a very long time. With this fix, the CRAN version of the package builds and checks fine on my Windows/aarch64 system using LLVM 17.

[eromero-vlc]

Thanks for reporting the issue, but it isn't that easy. The missing function in RLapack that primme needs is zhegv. zheev and zpotrf are dependencies of zhegv. I have hidden most of the symbols of zhegv.c and make zhegv_ weak. I've put the changes into the branch eloy/R-fix-zhegv-linking. Can you take a try?

[kalibera]

Ah, so my patch wouldn't work with static LAPACK_LIBS, right? Also your solution makes sense if you want to be sure that you're using your version of the dependencies with your zhegv_, when using your zhegv_.

I tried your commit on the CRAN version of the package and it works on LLVM/aarch on Windows (also x86_64/Windows).

The github version couldn't be built because of I am probably missing some config, but that is I assume unrelated.

/PRIMME_types.h:39:10: fatal error: 'c_interface/primme.h' file not found
   39 | #include "c_interface/primme.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~

[eromero-vlc]

Ah, so my patch wouldn't work with static LAPACK_LIBS, right? Also your solution makes sense if you want to be sure that you're using your version of the dependencies with your zhegv_, when using your zhegv_.

Yes, that's right.

I tried your commit on the CRAN version of the package and it works on LLVM/aarch on Windows (also x86_64/Windows).

Happy to hear that! I'll submit the new version tomorrow if the checks go well tonight.

The github version couldn't be built because of I am probably missing some config, but that is I assume unrelated.

/PRIMME_types.h:39:10: fatal error: 'c_interface/primme.h' file not found
   39 | #include "c_interface/primme.h"
      |          ^~~~~~~~~~~~~~~~~~~~~~

When primme is download from the repo, you may want to execute make update on <primme_home>/R before installing the R package.

[eromero-vlc]

My version fails with gcc 12.3 on windows :/ I'll think about it.

[kalibera]

I think for maintainability purposes, it is best to do something very simple, without relying on specifics of linkers. E.g., you can use external Lapack. On Windows, Rtools has a full lapack at least since Rtools42.

[eromero-vlc]

Yes, we have to do something simple. But we cannot work with the assumption that a full lapack will be installed. Because the r-cran tests are done without a full lapack, and you have to pass those tests to publish new versions of the primme package for R.

[kalibera]

I don't think this is true, other packages do it as well. On Windows, you can use external full lapack (-llapack or via pkg-config) unconditionally, because it is available in Rtools, it will be available also on the check machines and all user machines. I expect you can require (full) lapack on all platforms, if you do it the right way. Perhaps you can check other packages how they exactly do it (e.g. float, rsparse, RoBMA), check if it is in-line with the CRAN policy and Writing R Extensions, and if in doubt, ask on R-pkg-devel (and if that doesn't help, CRAN@r-project.org) - I am not the expert on this, I would be reading the manuals like you. But I checked with Prof. Ripley and using the external lapack is the preferred solution in this case.