Thanks for looking into this. For my case (2) (non-PDL SP 5.32.1.1, then PDL installed, then Math::GSL), which passes:

2.7.1 share
2.081
[download]

For my case (4) (PDL SP 5.32.1.1, then PDL upgraded, then Math::GSL installed), which fails:

2.6 system
2.081
[download]

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

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
[download]

You might need to then reinstall Math::GSL:

cpanm --reinstall Math::GSL
[download]

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.