Para responder a esta pergunta, realmente é necessário um entendimento completo do GNU autotools , o qual eu não tenho: no entanto, espero que estes comentários ajudem.
O script de configuração para uma construção específica é gerado a partir de seu arquivo configure.ac usando autoconf . Por sua vez, o configure.ac usa macros padrão para testar a presença de componentes especificados. Neste caso particular, configure.ac especifica um teste AC_CHECK_LIB para a biblioteca GSL como
AC_CHECK_LIB(gsl, gsl_sf_bessel_Jn, [],
[AC_MSG_WARN([Missing GNU GSL library...Bessel-function field initialization will not be supported.])])
A sintaxe de um AC_CHECK_LIB é
AC_CHECK_LIB (library, function, [action-if-found], [action-if-not-found], [other-libraries])
e o mecanismo real pelo qual a verificação é executada é criando um programa de teste mínimo ( conftest ) para a função especificada gsl_sf_bessel_Jn na biblioteca libgsl e tentando vinculá-lo usando as ferramentas de compilação padrão. Um programa tão mínimo pode parecer algo como
char gsl_sf_bessel_Jn();
int main() { return gsl_sf_bessel_Jn(); return 0; }
Note que o protótipo fictício char gsl_sf_bessel_Jn() pode não ter relação com o tipo de retorno ou com a lista de argumentos da função real - nós nunca tentamos executar o programa, apenas desejamos saber se ele vincula (ou seja, se o vinculador é capaz de resolver referências de biblioteca). Podemos ver como isso funciona se criarmos esse arquivo fonte por nós mesmos:
$ cat > conftest.c
char gsl_sf_bessel_Jn();
int main() { return gsl_sf_bessel_Jn(); return 0; }
Ctrl + D
Como esperado, se tentarmos executá-lo sem vincular a biblioteca GSL, obteremos um erro
$ gcc conftest.c
/tmp/ccWqFraS.o: In function 'main':
conftest.c:(.text+0xa): undefined reference to 'gsl_sf_bessel_Jn'
collect2: error: ld returned 1 exit status
No entanto, mesmo que explicitamente vinculemos libgsl , encontramos
$ gcc conftest.c -lgsl
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libgsl.so: undefined reference to 'cblas_dasum'
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libgsl.so: undefined reference to 'cblas_sger'
.
<snip>
.
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib/libgsl.so: undefined reference to 'cblas_zdotu_sub'
collect2: error: ld returned 1 exit status
Neste ponto, é importante observar que o script de configuração não sabe por que um teste em particular falhou, apenas isso. Nesse caso, falhou porque não vinculamos a biblioteca libgslcblas subordinada.
Isso ilustra a importância da ordem em que os testes são executados: cada teste bem-sucedido faz com que a biblioteca recém-descoberta seja adicionada à variável $LIB para testes subseqüentes. Especificamente (como observado na documentação da GSL )
O pacote de fontes meep faz checar por libgslcblas antes de libgsl, entretanto a checagem específica que ele faz é um AC_CHECK_FUNC ao invés de um AC_CHECK_LIB
AC_CHECK_FUNC(cblas_cgemm, [], [AC_CHECK_LIB(gslcblas, cblas_cgemm)])
Embora superficialmente semelhante, parece que AC_CHECK_FUNC não anexa a biblioteca a $LIBS em sucesso; parece que podemos contornar isso simplesmente adicionando um AC_CHECK_LIB explícito para libgslcblas no arquivo configure.ac
# GNU Scientific Library
AC_CHECK_FUNC(cblas_cgemm, [], [AC_CHECK_LIB(gslcblas, cblas_cgemm)])
AC_CHECK_LIB([gslcblas],[cblas_cgemm])
AC_CHECK_LIB(gsl, gsl_sf_bessel_Jn, [],
[AC_MSG_WARN([Missing GNU GSL library...Bessel-function field initialization will not be supported.])])
e, em seguida, executando autoconf para gerar novamente o script de configuração
$ autoconf
após o qual executar ./configure informa que a biblioteca GSL está realmente encontrada:
$ ./configure --prefix=/usr/local | grep gsl
configure: WARNING: Cannot find latex2html in your path!
configure: WARNING: FFTW needed for MPB
checking for cblas_cgemm in -lgslcblas... yes
checking for gsl_sf_bessel_Jn in -lgsl... yes