Opened 3 years ago

Closed 3 years ago

#922 closed defect (fixed)

configure: gsl check doesn't use detected blas

Reported by: Peter Owned by: Peter
Priority: major Milestone: yat 0.17
Component: build Version:
Keywords: Cc:

Description

This is reported by Jari when testing the 0.16 release.

Apple provides a cblas as /usr/lib/libcblas.dylib and atlas in installed in /opt/local/lib via macports which provides numerous libs, including:

libatlas.a
libsatlas.dylib
libtatlas.dylib
libcblas.a
libf77blas.a
libptcblas.a
libptf77blas.a

The configure scripts detects -lcblas (in /usr/lib/). Next configure looks for GSL and finds gsl-config under /opt/local adds -L/opt/local/lib to LDFLAGS and tests linking against -lgsl (plus libgslcblas or whatever is suggested by gsl-config --libs).

When linking the test programs we do that with

-L/opt/local/lib -lgsl -lcblas

which means that /opt/local/lib/libcblas.a is pulled in, which doesn't work becsuse that lib does not provile a complete CBLAS implementation (-latlas or similar is also needed).

We should not try to be smart and fix so this work, but it would be useful if the problem was detected already at configure time. This could, e.g., be tested by linking with flags and libs that is propagated to Makefile and used when building test programs.

Another idea is to use the GSL_CBLAS_LIB to make gsl-config to return the detected CBLAS lib(s), which means that one will be used at the link test for gsl (in configure). That would in this case result in gsl test to fail, which probably is confusing.

While writing this I realize that we could also bake the GSL and CLAS together with something like

  1. test for GSL (default)
  2. if 1 is successful, look if there is a "better" cblas lib. Test linking against -lgsl with different BLAS, in the same order as the current blas test, i.e., <empty>, -lcblas... Possibly use env variable GSL_CBLAS_LIB in order to use different CBLAS libs. That would most likely solve the problem in this case. With -L/opt/local the test against -lclas will fail and instead the atlas lib will be chosen.

Change History (3)

comment:1 Changed 3 years ago by Peter

Milestone: yat 0.x+yat 0.17
Owner: changed from Jari Häkkinen to Peter
Status: newaccepted

comment:2 Changed 3 years ago by Peter

In 3812:

Ticket #922 describes a case where the linked in lib is not the same
as the one tested at configure time. The problem was that the linker's
search path (LDFLAGS) was different at make time and at the time of
the CBLAS tests at configure time. To solve that, move the CBLAS tests
to after the gsl and boost have added -L paths to LDFLAGS.

refs #922

comment:3 Changed 3 years ago by Peter

Resolution: fixed
Status: acceptedclosed
Note: See TracTickets for help on using tickets.