gmt5: build fails on Mavericks: error: conflicting types for 'dsyev_'

[mp@…]

Extract from the log:

:info:build /opt/local/var/macports/build/_...dports_science_gmt5/gmt5/work/gmt-5.2.1/src/gmt_vector.c:693:13: error: conflicting types for 'dsyev_'
:info:build         extern int dsyev_ (char* jobz, char* uplo, int* n, double* a, int* lda, double* w, double* work, int* lwork, int* info);
:info:build                    ^
:info:build /System/Library/Frameworks/vecLib.framework/Headers/clapack.h:2800:5: note: previous declaration is here
:info:build int dsyev_(char *jobz, char *uplo, __CLPK_integer *n, __CLPK_doublereal *a, 
:info:build     ^
:info:build /opt/local/var/macports/build/_...dports_science_gmt5/gmt5/work/gmt-5.2.1/src/gmt_vector.c:699:38: warning: 
                incompatible pointer types passing 'int *' to parameter of type '__CLPK_integer *' (aka 'long *') [-Wincompatible-pointer-types]
:info:build         dsyev_ ( "Vectors", "Upper", &n, a, &lda, w, &wkopt, &lwork, &info );
:info:build                                      ^~
:info:build /System/Library/Frameworks/vecLib.framework/Headers/clapack.h:2800:52: note: passing argument to parameter 'n' here
:info:build int dsyev_(char *jobz, char *uplo, __CLPK_integer *n, __CLPK_doublereal *a, 
:info:build                                                    ^
[...]

Attaching full log file.

[mp@…]

complete failing build log

[tenomoto (Takeshi Enomoto)]

You are using an i386 machine. GMT tries to call dsyev_ of CLPACK with the pointer to int rather than that to long. I looked at clpack.h integer is defined to be long int. I believe long is 8 byte on Mac even if it is i386. I suspect that it is a problem of Accelerate.framework, not gmt5. I'll try to find further info.

[mojca (Mojca Miklavec)]

From what I understood in the emails exchanged on the list (I didn't investigate myself), I would call this "sloppy" coding, so something that could be fixed.

Why is gmt redefining dsyev_? If it has to do so, it would probably be worth trying whether it would work if you would modify gmt-5.2.1/src/gmt_vector.c and replace

extern int dsyev_ (char* jobz, char* uplo, int* n, double* a, ...

with

extern int dsyev_ (char *jobz, char *uplo, __CLPK_integer *n, __CLPK_doublereal *a, ...

[tenomoto (Takeshi Enomoto)]

The upstream had to provide a header to call a Fortran subroutine dsyev from C. Thus it is not a redefinition. The problem is __CLPK_integer could be 4 or 8-byte depending on the presence of symbol __LP64__. Now that universal_variant is suspected to the cause, I try to reproduce the problem. I'll try your suggestion and I think it will compile, but I don't think a pointer to 4-byte integer should be passed.

[tenomoto (Takeshi Enomoto)]

I was able to reproduce the problem with +universal. I was able to compile gmt_vector.c without error with the source edit suggested by Mojca. However I was able to compile the following source using dsyev_ adopted from ​http://www.jsces.org/Issue/Journal/pdf/nakata-0411.pdf (text in Japanese) with clang++ -arch i386 foo.cc -framework Accelerate. The result matches that built for x86_64. I'm confused...

//dsyev
#include <iostream>
#include <stdio.h>
extern "C" int dsyev_(const char *jobz, const char *uplo, int *n, double *a, int *lda, double *w, double *work, int *lwork, int *info); //Matlab/Octave format
void printmat(int N, int M, double *A, int LDA) {
  double mtmp;
  printf("[ ");
  for (int i = 0; i < N; i++) {
    printf("[ ");
    for (int j = 0; j < M; j++) {
      mtmp = A[i + j * LDA]; printf("%5.2e", mtmp);
      if (j < M - 1) printf(", ");
    } if (i < N - 1) printf("]; ");
   else printf("] ");
  } printf("]");
}
int main()
{
  int n=3;
  int lwork, info;
  double *A = new double[n*n]; double *w = new double[n];
  //setting A matrix
  A[0+0*n]=1;A[0+1*n]=2;A[0+2*n]=3; A[1+0*n]=2;A[1+1*n]=5;A[1+2*n]=4; A[2+0*n]=3;A[2+1*n]=4;A[2+2*n]=6;
  printf("A ="); printmat(n, n, A, n); printf("\n");
  lwork = -1;
  double *work = new double[1];
  dsyev_("V", "U", &n, A, &n, w, work, &lwork, &info); lwork = (int)work[0];
  delete[]work;
  work = new double[std::max((int) 1, lwork)]; //get Eigenvalue
  dsyev_("V", "U", &n, A, &n, w, work, &lwork, &info); //print out some results.
  printf("#eigenvalues \n"); printf("w ="); printmat(n, 1, w, 1); printf("\n"); printf("#eigenvecs \n"); printf("U ="); printmat(n, n, A, n); printf("\n"); printf("#Check Matlab/Octave by:\n"); printf("eig(A)\n");
  printf("U'*A*U\n"); delete[]work; delete[]w; delete[]A;
}

[tenomoto (Takeshi Enomoto)]

I found that Accelerate/Accelerate.h is included in gmt_fft.h and gmt_grdio.h. The error is only inconsistent headers. If (re)definition of dsyev_ is removed, the compile will succeed and 4-byte integers will be passed to dsyev_. Committed in r146902.

[tenomoto (Takeshi Enomoto)]

Reported to the upstream developers. ​http://gmt.soest.hawaii.edu/issues/876