[BioLib-dev] release candidate

[Xin Shuai]

Hi, Pjotr:  I don't have such kind of problem in my machine, but I did
revise the rng.c file in gsl library in ./contrib after I first pulled from
your libsequence branch and update the submodule.

  Actually speaking, what I did is restore rng.c file to its original state,
since I found that your ./contrib/gsl/rng/rng.c is different from the
original one(gsl-1.11 version). I don't know why it is modified in
./contrib/gsl directory (I once mentioned in my email and maybe you didn't
notice that). The difference between your ./contrib/gsl/rng/rng.c and the
original one is that, the modified file is missing the following part:

#ifndef HIDE_INLINE_STATIC

unsigned long int

gsl_rng_get (const gsl_rng * r)

{

  return (r->type->get) (r->state);

}


double

gsl_rng_uniform (const gsl_rng * r)

{

  return (r->type->get_double) (r->state);

}


double

gsl_rng_uniform_pos (const gsl_rng * r)

{

  double x ;

  do

    {

      x = (r->type->get_double) (r->state) ;

    }

  while (x == 0) ;


  return x ;

}


/* Note: to avoid integer overflow in (range+1) we work with scale =

   range/n = (max-min)/n rather than scale=(max-min+1)/n, this reduces

   efficiency slightly but avoids having to check for the out of range

   value.  Note that range is typically O(2^32) so the addition of 1

   is negligible in most usage. */


unsigned long int

gsl_rng_uniform_int (const gsl_rng * r, unsigned long int n)

{

  unsigned long int offset = r->type->min;

  unsigned long int range = r->type->max - offset;

  unsigned long int scale;

  unsigned long int k;


  if (n > range || n == 0)

    {

      GSL_ERROR_VAL ("invalid n, either 0 or exceeds maximum value of
generator",

                     GSL_EINVAL, 0) ;

    }


  scale = range / n;


  do

    {

      k = (((r->type->get) (r->state)) - offset) / scale;

    }

  while (k >= n);


  return k;

}

#endif


So I just added the following part to my./contrib/gsl/rng/rng.c. (The reason
I found this problem is that when I import libsequence in Python,
gsl_rng_uniform is reported missing. It really took me some time to figure
it out)

However, when I added that part,  which seems related with 'inline'
definition. Then I just remove the 'inline.cc' file name from the
gsl_file.txt list. And everything looked fine then. Therefore, I guess maybe
you modified the original file to avoid inline problem.




On Wed, Aug 12, 2009 at 3:15 AM, Pjotr Prins <pjotr.public14 at thebird.nl>wrote:

> Hi Xin,
>
> I renamed the test file so it gets found by Cmake.
>
> However, the test fails:
>
>  cd src/mappings/swig/python/libsequence
>  cmake .
>  make
>  make test
>
> gives:
>
>  Command: "/usr/bin/python" "./../test/test_libsequence.py"
>  Directory:
> /home/pjotr/data/git/opensource/biolib-libsequence/src/mappings/swig/python/libsequence
>  "TestPythonlibsequence" start time: Aug 12 08:59 CEST
>  Output:
>  ----------------------------------------------------------
>  Traceback (most recent call last):
>    File "./../test/test_libsequence.py", line 5, in <module>
>      from biolib.libsequence import *
>    File "biolib/libsequence.py", line 7, in <module>
>      import _libsequence
>  ImportError:
> /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/
> libbiolib_gsl-0.0.5.so: undefined symbol: gsl_rng_uniform_int
>
>
> This error is caused, most likely, because we build the gsl with inline
> functions.
>
>  INLINE_DECL unsigned long int gsl_rng_uniform_int (const gsl_rng *r,
> unsigned l ong int n);
>
> The INLINE is used for performance reasons (see
> http://www.greenend.org.uk/rjk/2003/03/inline.html) and is not visible
> outside
> the shared library itself. However SWIG thinks it is visible, because it is
> defined in gsl_rng.h) and has created a mapping for it. That is why the
> test
> fails. A first good case for an integration test :-)
>
> Can you find a way to tell SWIG *not* to create a mapping for this, and
> similar,
> declarations?
>
> But first you need to ascertain this test fails on your system. If it does
> not,
> I suspect your linker finds a different GSL shared library on your system -
> one
> that has the INLINE statement switched off. In Linux we can use something
> like
>
>  ldd libsequence-swig.so (or similar dylib)
>
> to find what libraries it links against. On my system it renders:
>
>  ldd biolib/_libsequence.so
>
>        linux-gate.so.1 =>  (0xb7f42000)
>        libbiolib_libsequence-0.0.5.so =>
> /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/libsequence-1.6.6/build/
> libbiolib_libsequence-0.0.5.so (0xb7acd000)
>        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb797f000)
>        libbiolib_gsl-0.0.5.so =>
> /home/pjotr/data/git/opensource/biolib-libsequence/src/clibs/biolib_gsl/build/
> libbiolib_gsl-0.0.5.so (0xb7735000)
>        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7647000)
>        libm.so.6 => /lib/i686/cmov/libm.so.6 (0xb7621000)
>        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb7614000)
>        libc.so.6 => /lib/i686/cmov/libc.so.6 (0xb74b8000)
>        libpthread.so.0 => /lib/i686/cmov/libpthread.so.0 (0xb749f000)
>        libdl.so.2 => /lib/i686/cmov/libdl.so.2 (0xb749b000)
>        libutil.so.1 => /lib/i686/cmov/libutil.so.1 (0xb7497000)
>        /lib/ld-linux.so.2 (0xb7f43000)
>
> You see it uses libbiolib_gsl-0.0.5.so
>
> Pj.
>
>


-- 
Xin Shuai (David)
PhD of Complex System in School of Informatics
Indiana University Bloomington
812-606-8019