AX_PATH_GSL fails if gslcblas is not available

[Peter]

I tried removing gslcblas and then AX_PATH_GSL fails with these warnings:

** Could not run GSL test program, checking why...
** The test program failed to compile or link. See the file config.log for the
** exact error that occured. This usually means GSL was incorrectly installed
** or that you have moved GSL since it was installed. In the latter case, you
** may want to edit the gsl-config script: /usr/bin/gsl-config

at the end of yat's configure it says

configure: WARNING:
        GSL found but not the required version. Please install
        GSL version 1.8 or later

which is not a very accurate description on what is going on.

This case is not very likely to occur because gslcblas is when gsl is installed. Nevertheless, if I choose to use another cblas e.g. atlas I think it is wrong that configure doesn't go through.

[Peter]

fixed in [1349]

[Jari Häkkinen]

Resolution in changeset:1349 pollutes users environment. Avoid this.

[Peter]

Note r1903 reintroduced this issue. I wouldn't mind closing this ticket as wontfix. Having a libgsl without libgslcblas could be considered as a broken installation. The problem with the inaccurate error message is ticket:526, which was fixed in 0.6pre.

[Jari Häkkinen]

Replying to peter:

Note r1903 reintroduced this issue. I wouldn't mind closing this ticket as wontfix. Having a libgsl without libgslcblas could be considered as a broken installation. The problem with the inaccurate error message is ticket:526, which was fixed in 0.6pre.

But the problem is NOT a missing libgslcblas, the issue is because the detection of cblas was not correct in configure.ac and the use of the finding in m4/gsl.m4 was wrong ... and the order of libs in linking was wrong. Of course, one could argue that gsl should only depend on its own cblas in testing for existence and version but currently it depends on whatever cblas configure finds.

If we want gsl.m4 to use only libgslcblas then this can be place in gsl.m4 with an option to override it with the environment variable.

The latest commits tries to solve several issues ... report problems and they'll be resolved quickly.

[Peter]

Replying to jari:

But the problem is NOT a missing libgslcblas,

Disagree, the problem reported here was a missing libgslcblas. I removed it intentionally to check this. Therefore, this issue is rather artificial and should have lowest possible priority.

the issue is because the detection of cblas was not correct in configure.ac and the use of the finding in m4/gsl.m4 was wrong ... and the order of libs in linking was wrong.

Yes, all those things were wrong, but that was not the problem here. The problem was that the test in gsl.m4 uses -lgslcblas when linking and if libgslcblas is gone it will fail. Again, this issue is rather artificial.

Of course, one could argue that gsl should only depend on its own cblas in testing for existence and version but currently it depends on whatever cblas configure finds.

But the problem is that it depends on whatever cblas plus its own cblas. I tried to fix so it only depended on whatever cblas and not its own cblas.