mvgrimes/pdl-opt-qp

undefined symbol: ddot_

Opened this issue · 10 comments

eserte commented

The test suite fails on some of my smoker systems --- it seems that mostly Ubuntu is affected (xenial, bionic, eoan):

...
Can't load '/home/cpansand/.cpan/build/2020021223/PDL-Opt-QP-0.27-2/blib/arch/auto/PDL/Opt/QP/QP.so' for module PDL::Opt::QP: /home/cpansand/.cpan/build/2020021223/PDL-Opt-QP-0.27-2/blib/arch/auto/PDL/Opt/QP/QP.so: undefined symbol: ddot_ at /usr/lib/x86_64-linux-gnu/perl/5.28/DynaLoader.pm line 187.
Compilation failed in require at t/00-load.t line 6.
BEGIN failed--compilation aborted at t/00-load.t line 6.
t/00-load.t ..... 
Dubious, test returned 2 (wstat 512, 0x200)
No subtests run 
...
mohawk2 commented

This will be due to the .so not being linked with BLAS. @mvgrimes Are you amenable to this module being updated? If so, are you happy to add me and @zmughal as collaborators on the repo, and grant us (ETJ and ZMUGHAL) co-maint on PAUSE? I have in mind to change this thing to use PDL::LinearAlgebra (which uses LAPACK rather than the LINPACK here) to simplify the code.

mvgrimes commented
mohawk2 commented

I really don't have the opportunity to use perl much these days, and I see you both have several quality modules on cpan. (I hadn't seen the implementation of GraphQL. I'm looking forward to exploring that.) I'll add you both as co-mainters, and thank you in advance for your work.

Thank you! If you add both of us as "collaborators" on this repo as well, that will enable us to update it here rather than have to make a fork?

Would you be interested in taking over Module::Build::Pluggable::Fortran and ::PDL as well?

Sure, why not :-)

mvgrimes commented

Thanks for the reminder. I've made both you and @zmughal collaborators on the repos and co-maintainers on cpan.

  • 👍1
mohawk2 commented

Thank you!

BaT's solve.QP calls:

  • dpofa from LINPACK
  • a supplied dposl
  • a customised dpori which is customised from LINPACK dpodi

Notes on converting this to use LAPACK:

  • LAPACK dposv calls dpotrf (seems equivalent to dpofa) then dpotrs, which together seem equivalent to the first two calls above
  • dpori is cut down from the LINPACK function dpodi, to not do the second part ("form inverse(r) * trans(inverse(r))" in the comment). The LAPACK equivalent function, dpotri, calls two utility functions, the first of which (dtrtri) does exactly the same

64-bit notes: PDL::LinearAlgebra's use of LAPACK is currently 32-bit only, so I don't see a major benefit in worrying about that here. The Warn64bit module, which is supposedly bundled in inc (and indeed on CPAN that is true), is not in the repo. However, given its purpose is to just give a warning on 64-bit-capable PDL (if indx exists), and cpanm doesn't by default show such warnings, I feel just a documentation note will suffice.

mohawk2 commented

I've added issue-notify (overriding repository_owner).

mohawk2 commented

I've done the above stuff, and cargo-culted the LAPACK-using stuff (and the Fortran naming stuff) from PDL::LinearAlgebra, which should mean the error from this report will happen only as much as it's likely in PDL::LinearAlgebra. I've also put out a dev-release so we can see if any of this works.

I am therefore closing this (thank you @eserte for the report!), but please comment if you see this still happening.

mohawk2 commented

Unfortunately https://www.cpantesters.org/cpan/report/65758d66-8f3f-11ed-8e90-f0406e8775ea shows a similar issue on one of @eserte's smokers, which is apparently a Red Hat box, but using a kernel version (6.0.8) that is beyond what https://en.wikipedia.org/wiki/Red_Hat_Enterprise_Linux shows for RHEL 9 (which is kernel version 5):

Can't load '/home/cpansand/.cpan/build/2023010809/PDL-Opt-QP-0.28-0/blib/arch/auto/PDL/Opt/QP/QP.so' for module PDL::Opt::QP: /home/cpansand/.cpan/build/2023010809/PDL-Opt-QP-0.28-0/blib/arch/auto/PDL/Opt/QP/QP.so: undefined symbol: dposv_ at /opt/perl-5.37.6/lib/5.37.6/x86_64-linux/DynaLoader.pm line 206.

I believe that to make sense of this, I'd need the output from the build, and specifically to understand what LAPACK library it found (if any) and linked to. It looks from the symbol-name that EU:F77 expects a trailing underscore, and it's not supposed to install if it can't build a simple Fortran program.

mohawk2 commented

The latest version of this module (0.29, which fixed my copy-pasting only partially from PDL::LinearAlgebra) reproduces this problem on my CentOS 7 VM, which is good news. Also good is achieving some clarity: the code calls Devel::CheckLib, which successfully tests compiling the supplied code, but does not run it due to not supplying any libs arguments to D:CL.

It really looks to me like we need an Alien::LAPACK that will capture the various bits of fiddliness in one place, rather than trying to maintain (at least) two copies. If I get to it first, then the first version will resemble Alien::Gimp and just captures configuration information, and not try to install anything (though probably not capturing that config into its own files, and instead calculating it every time, to facilitate switching LAPACK implementations).

cf PDLPorters/pdl-linearalgebra#19 and PDLPorters/pdl-linearalgebra#21 and PDLPorters/pdl-linearalgebra#15