Hi,
Strawberry's PDL build ships with gsl-2.6. (The non-PDL build does not include a gsl library, and I'm guessing that installing PDL into the non-PDL build will not, of itself, install a locatable gsl library.)
It seems that both "(3)" and "(4)" are using gsl-2.6, whereas both "(1)" and "(2)" are avoiding the issue by installing and using gsl-2.7.1.
It could be that "(3)" and/or "(4)" did install 2.7.1 (I don't know) but they still find and use the buggy 2.6 version that shipped with Strawberry Perl-5.32.1.1-PDL.
You just need to ensure that the non-buggy 2.7.1 gets loaded and used.
At least, that's how it looks to me.
Cheers,
Rob | [reply] |
Maybe it's a GSL version issue? What happens if you force a share install in your case 4 to ensure it upgrades?
set ALIEN_INSTALL_TYPE=share
cpanm Alien::GSL
You might need to then reinstall Math::GSL:
cpanm --reinstall Math::GSL
| [reply]
[d/l]
[select] |
I did as you suggested, now output line is
2.7.1 share
However my test script still fails as "1 1 1", and Math::GSL::gsl_version still says "2.6".
Same result with freshly unpacked "PDL edition SP 5.32.1.1", then env. variable set, then Alien::GSL and Math::GSL installed cleanly.
For now I'll continue with non-PDL SP and just install PDL if needed. I think long habit of choosing "PDL edition" as default is from time past, when PDL installation process had issues, it isn't the case in 2022. Thanks everyone for help.
| [reply]
[d/l]
[select] |
Updated:
However my test script still fails as "1 1 1", and Math::GSL::gsl_version still says "2.6".
That will be because your Math::GSL was built against the static GSL libs that shipped with the "PDL edition".
Once Math::GSL has been built against those static libs, it will continue to reference the behaviour provided by that library.
In addition to installing the gsl-2.7.1 shared library, you will then need to rebuild (and re-install) Math::GSL against that gsl-2.7.1 shared library before you will see the correct bahaviour,
I think long habit of choosing "PDL edition" as default is from time past, when PDL installation process had issues, it isn't the case in 2022
I'm pretty sure the problem is with the version of the static GSL libs that ship with the "PDL edition" (in c/lib).
It used to be the case that there were parts of Math::GSL functionality that required shared gsl libs, not static libs - though I think the problem your facing is probably just that there's a bug in version 2.6.
I don't know if that reliance on a shared gsl library is still present with Math::GSL. IIRC, it was not something that could be fixed trivially, so perhaps it's still an issue.
In any case, I agree that the best and easiest solution is to use the non-PDL edition if you wish to also use Math::GSL, assuming that works for you.
It didn't actually work for me. Running cpanm -i Alien::GSL seemed to go fine, but cpanm -i Math::GSL croaked with:
Running Build.PL
Checking for GSL using gsl-config
'gsl-config' is not recognized as an internal or external command,
operable program or batch file.
'gsl-config' is not recognized as an internal or external command,
operable program or batch file.
'gsl-config' is not recognized as an internal or external command,
operable program or batch file.
'gsl-config' is not recognized as an internal or external command,
operable program or batch file.
I probably just need to set some environment variable(s) appropriately, but these days I quickly lose interest in messing about when Module::Build and "Alien" libraries are involved.
Cheers,
Rob | [reply]
[d/l]
[select] |
