Making travis script work for gsl-master aka GSL 2.6

[hakonhagland]

This issue will discuss how make the travis test for gsl-master pass, also related to the discussion in pull request #172.

The first issue when testing against gsl-master in the travis build can be seen at line #5079 of this build log (for pull request #172): https://travis-ci.org/leto/math--gsl/jobs/597321360#L5079 : it says:

Unsupported GSL version!!! : 2.6 at Build.PL line 77.

which comes from line #323 in Ver2Func.pm : https://github.com/leto/math--gsl/blob/master/inc/Ver2Func.pm#L323 and this is because there is no 2.6 key in the array @ver2func at line #10 : https://github.com/leto/math--gsl/blob/master/inc/Ver2Func.pm#L10

I tried to add an empty entry to the array as suggested by @leto :

    "2.6" => {
        new => [
        ]
    },

and this makes the perl Build.PL finish with success. But now running Build fails
for swig/Interp.i:

$ swig -o xs/Interp_wrap.2.6.c -outdir pm/Math/GSL -perl5 -I/opt/gsl/gsl-master/include -w451,454 swig/Interp.i
swig/system.i:2: Error: previous definition of 'GSL_MINOR_VERSION'.
error : No such file or directory while building ( -I/opt/gsl/gsl-master/include -w451,454 ) xs/Interp_wrap.2.6.c in pm/Math/GSL from 'swig/Interp.i' at inc/GSLBuilder.pm line 208.

[leto]

@hakonhagland interesting, thanks for this well-written bug report 👍.

Most likely, an empty new array is not supported, so omit it. If that doesn't work, actually finding one new function that is added in GSL 2.6, and putting it in there, may fix the problem.

[hakonhagland]

@leto Ok that could be an issue... but to me it looks like the issue is rather related to the generated file swig/system.i, it looks like this:

#define GSL_MAJOR_VERSION 2
#define GSL_MINOR_VERSION 6

On the other hand the gsl include file gsl/gsl_version.h looks like this after installation:

[...]
#define GSL_VERSION "2.6+"
#define GSL_MAJOR_VERSION 2
#define GSL_MINOR_VERSION 6+
[...]

If you look at the source for swig/Interp.i note that it includes both system.i and gsl/gsl_version.h. I think the problem is that GSL_MINOR_VERSION is set to 6 in system.i, but on the other hand is set to 6+ in gsl_version.h, so the definitions do not agree.

It is not clear to me what is the purpose of the system.i file? When we already have the file gsl_version.h, why would we need system.i also?

[leto]

@hakonhagland I will have to look into this and report back. It seems that you have found a bug or perhaps GSL changed underneath us, which it often does, and we need to react.

[gregoa]

Debian has upgraded libgsl to 2.6 recently, which makes Math::GSL unhappy, as expected. Cf. https://bugs.debian.org/960011

[hakonhagland]

@gregoa Thanks for the information. I will have a look at it.

[hakonhagland]

This issue will discuss how make the travis test for gsl-master pass

If I run

swig2.0 -o xs/SF_wrap.1.15.c -outdir pm/Math/GSL -perl5 -I/tmp/gsl-master/include -w451,454 swig/SF.i

I get error:

/tmp/gsl-master/include/gsl/gsl_sf_legendre.h:375: Error: Syntax error in input(1).
error : No such file or directory while building ( -I/tmp/gsl-master/include -w451,454 ) xs/SF_wrap.1.15.c in pm/Math/GSL from 'swig/SF.i' at inc/GSLBuilder.pm line 208.

and at line 375 of gsl/gsl_sf_legendre.h we have:

INLINE_DECL size_t gsl_sf_legendre_array_index(const size_t l, const size_t m);

where INLINE_DECL is defined in gsl/gsl_inline.h as

/* In recent versiions of GCC, the inline keyword has two different
   forms: GNU and C99.

   In GNU mode we can use 'extern inline' to make inline functions
   work like macros.  The function is only inlined--it is never output
   as a definition in an object file.

   In the new C99 mode 'extern inline' has a different meaning--it
   causes the definition of the function to be output in each object
   file where it is used.  This will result in multiple-definition
   errors on linking.  The 'inline' keyword on its own (without
   extern) has the same behavior as the original GNU 'extern inline'.

   The C99 style is the default with -std=c99 in GCC 4.3.  

   This header file allows either form of inline to be used by
   redefining the macros INLINE_DECL and INLINE_FUN.  These are used
   in the public header files as

        INLINE_DECL double gsl_foo (double x);
        #ifdef HAVE_INLINE
        INLINE_FUN double gsl_foo (double x) { return x+1.0; } ;
        #endif
   
*/

#ifdef HAVE_INLINE
#  if defined(__GNUC_STDC_INLINE__) || defined(GSL_C99_INLINE) || defined(HAVE_C99_INLINE)
#    define INLINE_DECL inline  /* use C99 inline */
#    define INLINE_FUN inline
#  else
#    define INLINE_DECL         /* use GNU extern inline */
#    define INLINE_FUN extern inline
#  endif
#else
#  define INLINE_DECL /* */
#endif

[leto]

@hakonhagland you need to give a lot more details like exact compiler version. Also, you are manually compiling and it can't find some files, I would not do that. Run the build script and see what errors it gets. What it comes down to, is Math::GSL needs to be updated to support the latest GSL 2.6, including telling it all new function and changed API's

[hakonhagland]

@leto Thanks for the tip! I was running on Ubuntu 14.04 with swig version 2.0 and gsl-master. There seems to many unrelated errors. I am trying to untangle it. One of the errors seems to be related to commit b26ab87 :

 #if definded GSL_MINOR_VERSION &&  GSL_MINOR_VERSION >= 12
   %include "gsl/gsl_inline.h"

notice that this commit was from 2009 and then the major version was at version 1 and minor version at 12. Now we are at major version 2 and minor version 6. And it seems the #if returns false now since minor version is 6, which is unfortunate because gsl_inline.h needs to be included it seems

[leto]

@hakonhagland this seems like a genuine bug. That conditional should be smarter, and handle GSL_MINOR_VERSION in a smarter way, based on GSL_MAJOR_VERSION being 1 or 2 . That should fix the issue

[hakonhagland]

@leto wrote:

this seems like a genuine bug.

Yes it does! And the fix was included in merged commit a202f4f.

I am looking at the failed tests for #179, there is one thing I do not understand with the travis build log output. For example, if we look at the first build 18 https://travis-ci.org/github/leto/math--gsl/jobs/684820428 at line 5713 it
says:

Processing 2.5 XS files, GSL 2.6 (via gsl-config) at /tmp/gsl-master

why does it say "2.5 XS files" and not "2.6 XS files" ? Compare with build 1 for GSL 2.5 there it says line 6051:

Processing 2.5 XS files, GSL 2.5 (via gsl-config) at /tmp/gsl-2.5

and for build 2 for GSL 2.4 it says:

Processing 2.4 XS files, GSL 2.4 (via gsl-config) at /tmp/gsl-2.4

Another thing that I do not understand is where the .c files comes from at line 5724 :

cc -I/home/travis/perl5/perlbrew/perls/5.24.0/lib/5.24.0/x86_64-linux/CORE -c -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -fPIC -I/tmp/gsl-master/include -fwrapv -fno-strict-aliasing -pipe -fstack-protector -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -Wall -Wno-sometimes-uninitialized -Wno-unused-function -Wno-unused-value -Wno-unused-function -Wno-unused-variable -Wno-gnu -g -fPIC -fno-omit-frame-pointer -I/tmp/gsl-master/include -o xs/Diff_wrap.2.5.o xs/Diff_wrap.2.5.c

I cannot see that the C file Diff_wrap.2.5.c has been generated in the log output. There should be a line like:

swig -o xs/Diff_wrap.2.5.c -outdir pm/Math/GSL -perl5 -I/opt/gsl/master/include -w451,454 swig/Diff.i

but I cannot find it...