guillaumegomez/rust-gsl

A GSL (the GNU Scientific Library) binding for Rust

rust-GSL

A Rust binding for the GSL library (the GNU Scientific Library).

The minimum support Rust version is 1.54.

Installation

This binding requires the GSL library library (version >= 2) to be installed:

Linux

# on debian based systems:
sudo apt-get install libgsl0-dev

macOS

brew install gsl

Apple silicon

Homebrew installs libraries under /opt/homebrew/include on Apple silicon to maintain backward compatibility with Rosetta 2.

After gsl has been installed in the usual way, use the environment variable:

RUSTFLAGS='-L /opt/homebrew/include'

before cargo run, cargo build, etc., to tell the compiler where gsl is located.

Windows

Instructions are available there: https://www.gnu.org/software/gsl/extras/native_win_builds.html.

Usage

This crate works with Cargo and is on crates.io. Just add the following to your Cargo.toml file:

[dependencies]
GSL = "7.0"

You can see examples in the examples folder.

Building

To build rgsl, just run cargo build. However, if you want to use a specific version, you'll need to use the cargo features. For example:

cargo build --features v2_1

If a project depends on this version, don't forget to add in your Cargo.toml:

[dependencies.GSL]
version = "2"
features = ["v2_1"]

Documentation

You can access the rgsl documentation locally, just build it:

> cargo doc --open

You can also access the latest build of the documentation via the internet here.

License

rust-GSL is a wrapper for GSL, therefore inherits the GPL license.

rust-gsl's Issues

Spline::init can read uninitialized memory

rust-GSL/src/types/interpolation.rs

Line 111 in 234cfc2

ya.as_ptr(),

The size of ya is never checked, and is simply assumed to be valid for xa.len() elements. If xa.len() is larger than the size passed to Spline::new(), the gsl error handler is called. But if the length of ya doesn't match, no such error occurs. I wonder if this should assert_eq!(xa.len(), ya.len())?

Error linking rust-GSL 0.4.26

Error linking simple program (https://github.com/ruivieira/scrapyard/tree/master/gibbs) using the GSL crate.

Command: cargo build

Output:

   Compiling libc v0.2.10
   Compiling num-traits v0.1.32
   Compiling rustc-serialize v0.3.19
   Compiling c_vec v1.0.12
   Compiling rand v0.3.14
   Compiling num-integer v0.1.32
   Compiling num-iter v0.1.32
   Compiling num-bigint v0.1.32
   Compiling num-complex v0.1.32
   Compiling num-rational v0.1.32
   Compiling num v0.1.32
   Compiling GSL v0.4.26
error: linking with `cc` failed: exit code: 1

...

 = note: Undefined symbols for architecture x86_64:
            "_gsl_sf_legendre_array_size", referenced from:
                rgsl::legendre::associated_polynomials::legendre_array_size::had397dab94a5cec9 in rgsl-d0fa51373d34118d.0.o
            "_gsl_sf_legendre_sphPlm_deriv_array", referenced from:
                rgsl::legendre::associated_polynomials::legendre_sphPlm_deriv_array::h4437735f828f055a in rgsl-d0fa51373d34118d.0.o
            "_gsl_sf_legendre_sphPlm_array", referenced from:
                rgsl::legendre::associated_polynomials::legendre_sphPlm_array::h995ab4ea64235b3d in rgsl-d0fa51373d34118d.0.o
            "_gsl_bspline_deriv_alloc", referenced from:
                rgsl::types::basis_spline::BSpLineDerivWorkspace::new::h6a0ffaf3b90ac39d in rgsl-d0fa51373d34118d.0.o
            "_gsl_bspline_deriv_free", referenced from:
                _$LT$rgsl..types..basis_spline..BSpLineDerivWorkspace$u20$as$u20$core..ops..Drop$GT$::drop::hbe616f29eb6a5bd0 in rgsl-d0fa51373d34118d.0.o
            "_gsl_sf_legendre_Plm_array", referenced from:
                rgsl::legendre::associated_polynomials::legendre_Plm_array::he622b32a4276b391 in rgsl-d0fa51373d34118d.0.o
            "_gsl_sf_legendre_Plm_deriv_array", referenced from:
                rgsl::legendre::associated_polynomials::legendre_Plm_deriv_array::hb3cebea101722fd0 in rgsl-d0fa51373d34118d.0.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

rustc --version: rustc 1.19.0 (0ade33941 2017-07-17)
cargo --version: cargo 0.20.0 (a60d185c8 2017-07-13)

Incorrect ffi-binding to gsl_multifit_function_fdf

GSL header gsl_multifit_nlin.h specifies gsl_multifit_function_fdf as

struct gsl_multifit_function_fdf_struct
{
  int (* f) (const gsl_vector * x, void * params, gsl_vector * f);
  int (* df) (const gsl_vector * x, void * params, gsl_matrix * df);
  int (* fdf) (const gsl_vector * x, void * params, gsl_vector * f, gsl_matrix *df);
  size_t n;       /* number of functions */
  size_t p;       /* number of independent variables */
  void * params;  /* user parameters */
  size_t nevalf;  /* number of function evaluations */
  size_t nevaldf; /* number of Jacobian evaluations */
};

typedef struct gsl_multifit_function_fdf_struct gsl_multifit_function_fdf ;

but Rust ffi binding misses last two fields:

rust-GSL/src/ffi/solvers.rs

Lines 150 to 168 in b06c673

	#[repr(C)]
	pub struct gsl_multifit_function_fdf {
	pub f:
	Option<extern "C" fn(x: *mut gsl_vector, params: *mut c_void, f: *mut gsl_vector) -> c_int>,
	pub df: Option<
	extern "C" fn(x: *mut gsl_vector, params: *mut c_void, df: *mut gsl_matrix) -> c_int,
	>,
	pub fdf: Option<
	extern "C" fn(
	x: *mut gsl_vector,
	params: *mut c_void,
	f: *mut gsl_vector,
	df: *mut gsl_matrix,
	) -> c_int,
	>,
	pub n: size_t,
	pub p: size_t,
	pub params: *mut c_void,
	}

I noticed this when saw undefined behaviour of my Rust code: some of my variables are changed by MultiFitFSolver::set(), but I didn't passed them there. Probably it also can cause problems described by #67

bad link on crates.io

On crate.io the link to the latest build info ("You can also access the latest build of the documentation via the internet here.") is currently going to some celebrity news site: http://rust-ci.org/GuillaumeGomez/rust-GSL/doc/rgsl/

Trouble with linking

Hi! First of all thak you for this amazing crate!
I opened an issue in Pyo3 repo as I want to use my code written in Rust (which uses this crate) from Python. The problem is that in the issue the author mentioned that It could be a link problem of this crate.
I honestly do not know how library linking works, so I opened this issue to know if I'm missing something or if there is a problem in this repo with gsl-sys.
P.D: Sorry about my English

math in doc

It would be nicer if we can support math in the doc, as in here.

Given there is a lot of math in the doc, I'm wonder how the docstring in this lib are created and if we can add $ symbols and escape some characters (e.g., []_) automatically.

Seg Fault using Minimization and Root

Hi,

I was working with the library and ran into a Segfault when trying the root and minimization functions. Perhaps I'm missing how you intended them to be applied.

Running Rust 1.54 on MacOS 11.5.2 with GSL 2.7.

anyway here's an MWE for the minimizer. However, the application for roots is the same but with a different convergence check:

#[cfg(test)]
mod test {
    use super::*;
    use minimizer::test_interval;
    extern crate assert_approx_eq;

    fn quadratic_test_fn(x: f64) -> f64 {
        x.powf(2.0) - 5.0
    }

    #[test]
    fn test_min() {
        let mut min = Minimizer::new(MinimizerType::brent()).unwrap();
        min.set(&quadratic_test_fn, 1.0, -5.0, 5.0);

        let max_iter = 5_usize;
        let eps_abs = 0.0001;
        let eps_rel = 0.0000001;

        let mut status = ::Value::Continue;
        let mut iter = 0_usize;

        while matches!(status, ::Value::Continue) && iter < max_iter {
            // iterate for next value
            status = min.iterate();  // fails here w/ segfault

            // test for convergence
            let r = min.minimum();
            let x_lo = min.x_lower();
            let x_hi = min.x_upper();

            status = test_interval(x_lo, x_hi, eps_abs, eps_rel);

            // check if iteration succeeded
            if matches!(status, ::Value::Success) {
                println!("Converged");
            }

            // print current iteration
            println!("{} [{}, {}] {} {}",iter, x_lo, x_hi, r, x_hi - x_lo);

            iter += 1;
        }

        assert_approx_eq::assert_approx_eq!(min.minimum(), 0.0_f64.sqrt())
    }
}

The failure occurs when calling min.iterate().

Here's the output:

running 1 test
error: test failed, to rerun pass '-p GSL --lib'

Caused by:
  process didn't exit successfully: `/rust-GSL/target/debug/deps/rgsl-13d5c769f322bfbb 'types::minimizer::test' --show-output --nocapture` (signal: 11, SIGSEGV: invalid memory reference)

Linking to GSL is failing

I've tried for hours now to successfully link GSL and my rust project.

The error:

error: linking with `x86_64-w64-mingw32-gcc` failed: exit code: 1
  |
  = note: "x86_64-w64-mingw32-gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\msys64\\mingw64\\x86_64-w64-mingw32\\lib\\dllcrt2.o" "C:\\Users\\Tyler\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\msys64\\mingw64\\x86_64-w64-mingw32\\lib" "-L" "C:\\Users\\Tyler\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.0.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.1.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.10.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.11.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.12.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.13.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.14.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.15.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.2.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.3.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.4.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.5.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.6.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.7.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.8.rcgu.o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.rgsl.2rvoy63y-cgu.9.rcgu.o" "-o" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.dll" "-Wl,--version-script=C:\\Users\\Tyler\\AppData\\Local\\Temp\\rustclFfSRB\\list" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.4ehqnvh7q6k2v6s7.rcgu.o" "-nodefaultlibs" "-L" "C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps" "-L" "/mingw64/lib" "-L" "C:\\Users\\Tyler\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-lgsl" "-lgslcblas" "-lm" "-L" "C:\\Users\\Tyler\\Documents\\GitHub\\rust_asf\\target\\debug\\deps" "-lc_vec-75e7b74152ad26ab" "-Wl,-Bstatic" "-Wl,--whole-archive" "C:\\Users\\Tyler\\AppData\\Local\\Temp\\rustclFfSRB\\liblibc-b1f278e3ea3e8abf.rlib" "-Wl,--no-whole-archive" "-Wl,--start-group" "-L" "C:\\Users\\Tyler\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bdynamic" "-lstd-492039e7b59897c1" "-Wl,--end-group" "-Wl,-Bstatic" "C:\\Users\\Tyler\\AppData\\Local\\Temp\\rustclFfSRB\\libcompiler_builtins-cf2c747a9d7d25a8.rlib" "-Wl,-Bdynamic" "-ladvapi32" "-lws2_32" "-luserenv" "-shared" "-Wl,--out-implib,C:\\Users\\Tyler\\Documents\\Github\\rust_asf\\target\\debug\\deps\\rgsl-d2020b8b123b005d.dll.lib" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\Tyler\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: ld: cannot find -lgsl
          ld: cannot find -lgslcblas

Platform: Windows 10. Rust 1.42 and rust is set to stable-gnu.
I've installed Msys, and followed

cd gsl/
./configure --enable-maintainer-mode
make
make install

Enforce borrowing (by writing a macro)

Since I added the soft_wrap, I think it could be improved further. Instead of having a pointer, we could have a wrapper on a pointer (a Rc-like) which would then call the corresponding free function.

Wrong type of argument to rgsl::fit::linear

rgsl::fit::linear takes a sumsq: f64, cf its signature:

fn linear(x: &[f64], xstride: usize, y: &[f64], ystride: usize, n: usize, c0: &mut f64, c1: &mut f64, cov00: &mut f64, cov01: &mut f64, cov11: &mut f64, sumsq: f64) -> enums::Value

The wrapper then also calls the function with the value. However, gsl_fit_linear takes a double * sumsq in its last position:

int gsl_fit_linear(const double * x, const size_t xstride, const double * y, const size_t ystride, size_t n, double * c0, double * c1, double * cov00, double * cov01, double * cov11, double * sumsq)

Genericity over f32 and f64

I need to do a FFT to a buffer of f32 audio samples. To prevent needless copying and converting, it would be nice if rust-GSL provided genericity over f32 and f64.

If I understand GSL correctly, it needs to be built separately for 32-bit floats and 64-bit floats. However, I think that linking both libraries is possible, and thus, I think that having the APIs over a generic Float and impls for f32 calling the 32-bit version and impls for f64 calling the 64-bit version would be feasible.

What do you think?

split ffi out

glfixed_point is broken

gsl_integration_glfixed_point only returns a single (node, weight) pair and does not write all nodes and weights to arrays as implied here:

rust-GSL/src/types/integration.rs

Lines 818 to 824 in c21148f

	sys::gsl_integration_glfixed_point(
	a,
	b,
	xi.len() as _,
	xi.as_mut_ptr(),
	wi.as_mut_ptr(),
	self.unwrap_shared(),

Add multifit_solver binding

Some links:

• https://github.com/ampl/gsl/blob/644e768630841bd085cb7121085a688c4ff424d0/multifit_nlinear/trust.c#L588
• https://www.gnu.org/software/gsl/manual/html_node/Nonlinear-Least_002dSquares-Initialization.html

cc @SuperFluffy

How to install dependency on Mac?

I've installed gsl, but looks like it wasn't enough:

>$ brew install gsl
==> Downloading https://homebrew.bintray.com/bottles/gsl-2.2.1.sierra.bottle.tar.gz
######################################################################## 100.0%
==> Pouring gsl-2.2.1.sierra.bottle.tar.gz
🍺  /usr/local/Cellar/gsl/2.2.1: 272 files, 8.6M

Here's the error when I try to build:

>$ cargo build
   Compiling GSL v0.4.28
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-m64" "-L" "/usr/local/lib/rustlib/x86_64-apple-darwin/lib" "/Users/franciswang/test/target/debug/deps/rgsl-6e9ac6569d203bcd.0.o" "-o" "/Users/franciswang/test/target/debug/deps/librgsl-6e9ac6569d203bcd.dylib" "/Users/franciswang/test/target/debug/deps/rgsl-6e9ac6569d203bcd.metadata.o" "-Wl,-dead_strip" "-nodefaultlibs" "-L" "/Users/franciswang/test/target/debug/deps" "-L" "/usr/local/lib/rustlib/x86_64-apple-darwin/lib" "-l" "gsl" "-l" "gslcblas" "-Wl,-force_load,/var/folders/x_/c899j8zj1p9617nktzy_55k00000gp/T/rustc.l05wzdpO5EaY/liblibc-6ec63c5a0e74a074.rlib" "-L" "/Users/franciswang/test/target/debug/deps" "-l" "c_vec-404a8700dec5f2e1" "-L" "/usr/local/lib/rustlib/x86_64-apple-darwin/lib" "-l" "std-a4729905" "/var/folders/x_/c899j8zj1p9617nktzy_55k00000gp/T/rustc.l05wzdpO5EaY/libcompiler_builtins-a4729905.rlib" "-l" "System" "-l" "pthread" "-l" "c" "-l" "m" "-dynamiclib" "-Wl,-dylib"
  = note: Undefined symbols for architecture x86_64:
  "_gsl_sf_legendre_array_size", referenced from:
      rgsl::legendre::associated_polynomials::legendre_array_size::hba1a0292657ad723 in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_sf_legendre_sphPlm_deriv_array", referenced from:
      rgsl::legendre::associated_polynomials::legendre_sphPlm_deriv_array::h5e62b502224dfcf2 in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_sf_legendre_sphPlm_array", referenced from:
      rgsl::legendre::associated_polynomials::legendre_sphPlm_array::hca6ca3693272788e in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_bspline_deriv_alloc", referenced from:
      rgsl::types::basis_spline::BSpLineDerivWorkspace::new::h15a8433a124eadb4 in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_bspline_deriv_free", referenced from:
      _$LT$rgsl..types..basis_spline..BSpLineDerivWorkspace$u20$as$u20$core..ops..Drop$GT$::drop::he88b99acc9916c98 in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_sf_legendre_Plm_array", referenced from:
      rgsl::legendre::associated_polynomials::legendre_Plm_array::h61d8ad280cb37285 in rgsl-6e9ac6569d203bcd.0.o
  "_gsl_sf_legendre_Plm_deriv_array", referenced from:
      rgsl::legendre::associated_polynomials::legendre_Plm_deriv_array::hb8b0d48c1dd07921 in rgsl-6e9ac6569d203bcd.0.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)


error: aborting due to previous error

error: Could not compile `GSL`.

To learn more, run the command again with --verbose.

MultifitSolver isn't working

Module.

enum 'EigenSort' is private

I am using the symmv_sort function to sort Eigenvalues + Eigenvectors, however I get an error saying that the EigenSort enum is private.

Looking at the source code on Github it's not private?

Also, the documentation page lists the enum under "rgsl::enums::EigenSort" but it's at "rgsl::enums::eigen_sort::EigenSort"?

Enforcing rust mutability rules ?

Hi, I just started to look at this library planning to probably use it for some projects.

From what I see, for example VectorF32::set(..) takes a &self reference, while according to rust mutability rules, you would expect it to require a &mut self reference. There are a lot of similar situations all around the binding.

Is it intended ?
(If not, I could maybe start working on fixing it everywhere appropriate, if I find some time.)

Incorrect documentation, and possible function names, for gamma distributions

The functions in rgsl::randist::gamma have improper documentation, and possible function names. Functions such as gamma_P, gamma_Q, gamma_Pinv, and gamma_Qinv say the compute the pdf in the rgsl documentation, but the gnu documentation for the functions called says they compute the cdf. P and Q are explained here.

The documentation should be updated. Perhaps the function names could be changed as well, but that would be a breaking change and probably not worth it.

Allow set_error to use closure instead of function

The problem is currently to return it.

Not Catching Bessel Underflows?

I'm trying to use some of the Bessel functions and want to catch cases where they should underflow, and unfortunately it seems like the error is generated but not caught.

As a minimal example, here's a small program that uses the K0_e Bessel function

extern crate rgsl;

use rgsl::{bessel, Value};

fn main() {
    match bessel::K0_e(1e0) {
        (Value::Success, r) => println!("K0(1e0) = {:.3e}", r.val),
        _ => unimplemented!(),
    }

    match bessel::K0_e(1e3) {
        (Value::Success, r) => println!("K0(1e3) = {:.3e}", r.val),
        (Value::UnderFlow, r) => println!("K0(1e3) underflowed: {:.3e}", r.val),
        _ => unimplemented!(),
    }
}

and the output is:

 ❯ cargo run
   Compiling gsl-bug v0.1.0 (/tmp/josh/gsl-bug)                                                                                                                                                                     
    Finished dev [unoptimized + debuginfo] target(s) in 0.38s                                                                                                                                                       
     Running `/home/josh/.cache/cargo/debug/gsl-bug`
K0(1e0) = 4.210e-1
gsl: exp.c:257: ERROR: underflow
Default GSL error handler invoked.
[1]    23445 abort (core dumped)  cargo run

Is this a bug with the Rust bindings to GSL, or is it an actual bug with GSL?

Unresolved external symbol

I'm trying to add support for vcpkg as I've found out, that I need to link to this with stable-msvc.

I'm beyond frustrated at this point, but here's where I am at: The build.rs I have right now is this:

extern crate vcpkg;
use std::path::PathBuf;

fn main() {
    std::env::set_var("VCPKGRS_DYNAMIC", "");
    std::env::set_var("RUSTFLAGS", "-Ctarget-feature=+crt-static");
    let gsl_library = vcpkg::Config::new()
        .cargo_metadata(true)
        .emit_includes(true)
        // .copy_dlls(true)
        // .vcpkg_root(PathBuf::from("C:/DEV/vcpkg/"))
        .find_package("gsl")
        .unwrap();
    dbg!(gsl_library);
    println!(r#"cargo:rustc-cfg=feature="v2""#);
}

I've also added default = ["v2"] to Cargo.toml to ensure that it is building the version of gsl that I installed through vcpkg.

The vcpkg crate works like this: If all this was resolved correlty, then the necessary things are emitted.

But I still get all of these as unresolved symbols: They aren't strictly v2 stuff, so I am just very perplexed as to why I'm missing 79 symbols:

``` gsl_odeiv2_step_rk2 gsl_odeiv2_step_rk4 gsl_odeiv2_step_rkf45 gsl_odeiv2_step_rkck gsl_odeiv2_step_rk8pd gsl_odeiv2_step_rk1imp gsl_odeiv2_step_rk2imp gsl_odeiv2_step_rk4imp gsl_odeiv2_step_bsimp gsl_odeiv2_step_msadams gsl_odeiv2_step_msbdf gsl_odeiv2_control_scaled gsl_odeiv2_control_standard gsl_interp_linear gsl_interp_polynomial gsl_interp_cspline gsl_interp_cspline_periodic gsl_interp_akima gsl_interp_akima_periodic gsl_rng_default_seed gsl_rng_default gsl_multifit_fdfsolver_lmder gsl_multifit_fdfsolver_lmsder gsl_qrng_niederreiter_2 gsl_qrng_sobol gsl_qrng_halton gsl_qrng_reversehalton gsl_rng_mt19937 gsl_rng_ranlxs0 gsl_rng_ranlxs1 gsl_rng_ranlxs2 gsl_rng_ranlxd1 gsl_rng_ranlxd2 gsl_rng_ranlux gsl_rng_ranlux389 gsl_rng_cmrg gsl_rng_mrg gsl_rng_taus gsl_rng_taus2 gsl_rng_gfsr4 gsl_rng_ranf gsl_rng_ranmar gsl_rng_r250 gsl_rng_tt800 gsl_rng_vax gsl_rng_transputer gsl_rng_randu gsl_rng_minstd gsl_rng_uni gsl_rng_uni32 gsl_rng_slatec gsl_rng_zuf gsl_rng_knuthran2 gsl_rng_knuthran2002 gsl_rng_knuthran gsl_rng_borosh13 gsl_rng_fishman18 gsl_rng_fishman20 gsl_rng_lecuyer21 gsl_rng_waterman14 gsl_rng_fishman2x gsl_rng_coveyou gsl_rng_rand gsl_rng_random_bsd gsl_rng_random_libc5 gsl_rng_random_glibc2 gsl_rng_rand48 gsl_root_fsolver_bisection gsl_root_fsolver_brent gsl_root_fsolver_falsepos gsl_root_fdfsolver_newton gsl_root_fdfsolver_secant gsl_root_fdfsolver_steffenson gsl_wavelet_daubechies gsl_wavelet_daubechies_centered gsl_wavelet_haar gsl_wavelet_haar_centered gsl_wavelet_bspline gsl_wavelet_bspline_centered ```

legendre_Pl_array and legendre_Pl_deriv_array are broken

The gsl docs state:

These functions compute arrays of Legendre polynomials P_l(x) and derivatives dP_l(x)/dx for l = 0, \dots, lmax and |x| \le 1.

That is the parameter l is not the size of the array for the results. Thus the following is wrong:

rust-GSL/src/legendre.rs

Line 75 in c21148f

sys::gsl_sf_legendre_Pl_array(result_array.len() as i32, x, result_array.as_mut_ptr())

Like that gsl tries to write to the address after the last array element resulting in undefined behavior.

Add doc alias check for ffi_wrap types

Like https://github.com/GuillaumeGomez/rust-GSL/blob/master/src/types/multiroot.rs#L106-L108

Feature request: add static linking option

It would be nice if the crate supports static linking with the GSL via a Cargo feature flag. The most of scientific crates with bindings provide such an option, e.g. ndarray-linalg, fftw, netcdf and hdf5

multifit_solver example broken: covariance matrix must be square and match second dimension of jacobian

I am trying out the GSL bindings, and wanted to run/build the multifit_solver example. Right off the bat I am getting the following error (following the other stdout at the beginning). Any idea what's going on?

% cargo run --example multifit_solver
    Finished dev [unoptimized + debuginfo] target(s) in 0.02s
     Running `target/debug/examples/multifit_solver`
data:  0 6.01339 0.10000
data:  1 5.51538 0.10000
data:  2 5.26109 0.10000
data:  3 4.77746 0.10000
data:  4 4.45135 0.10000
data:  5 3.90490 0.10000
data:  6 3.50439 0.10000
data:  7 3.41500 0.10000
data:  8 3.24274 0.10000
data:  9 3.12220 0.10000
data: 10 2.83763 0.10000
data: 11 2.53470 0.10000
data: 12 2.43917 0.10000
data: 13 2.38083 0.10000
data: 14 2.31609 0.10000
data: 15 2.06083 0.10000
data: 16 1.94568 0.10000
data: 17 1.91413 0.10000
data: 18 1.75951 0.10000
data: 19 1.66507 0.10000
data: 20 1.73793 0.10000
data: 21 1.57552 0.10000
data: 22 1.52507 0.10000
data: 23 1.40961 0.10000
data: 24 1.39521 0.10000
data: 25 1.41689 0.10000
data: 26 1.37604 0.10000
data: 27 1.26095 0.10000
data: 28 1.28963 0.10000
data: 29 1.42267 0.10000
data: 30 1.22829 0.10000
data: 31 1.19918 0.10000
data: 32 1.18999 0.10000
data: 33 0.93008 0.10000
data: 34 1.22461 0.10000
data: 35 1.14738 0.10000
data: 36 1.11400 0.10000
data: 37 1.19512 0.10000
data: 38 1.26958 0.10000
data: 39 1.06198 0.10000
iter: 0 x = 1 0 0 |f(x)| = 117.34877131716345
status = Success
iter: 1 x = 1.6465626049841333 0.018145550177925462 0.6465626049841325 |f(x)| = 76.45936553723283
gsl: covar.c:52: ERROR: covariance matrix must be square and match second dimension of jacobian
Default GSL error handler invoked.
zsh: abort (core dumped)  cargo run --example multifit_solver

MonteCarlo module not working correctly

Module.

Some `MultiFitFSolver` methods returns a `VectorF64` object with no lifetime bound

Whereas the returned objects should not live longer than MultiFitFSolver.

Project should be split into GSL versions to avoid linker errors

Currently if the project is built against the current GSL then it causes linker errors from deprecated functions. This makes the project very hard to use. Can we split it into a version scheme that matches GSL versions? Then make it so that the user should use that version. I would suggest for 1.6 or other GSL versions the code should be branched and then for the current 2.4 it should be branched as well. Then the user can chose the GSL version that fits their system. I would be happy to help.

Matrix Transpose

The function fn transpose_memcpy(&self) -> Option<(MatrixF32, Value)> does not work for rectangular Matricies.

Build on Windows using `vcpkg`

I've finally got this to work on the recommended rust toolchain. Previously discussed here #53 and #75.
On Windows, we are recommended to use stable-msvc / nightly-msvc.

You can install that using scoop, or manually here https://github.com/microsoft/vcpkg#quick-start-windows

scoop install vcpkg

Then, you set the following environment variables globally

VCPKG_DEFAULT_TRIPLET=x64-windows-static-md
VCPKG_INSTALLED_DIR=C:/Users/minin/scoop/apps/vcpkg/current/installed
LIB=%VCPKG_INSTALLED_DIR%/%VCPKG_DEFAULT_TRIPLET%/lib
INCLUDE=%VCPKG_INSTALLED_DIR%/%VCPKG_DEFAULT_TRIPLET%/include

That's it, this made my test project compile just fine.

Use of these environment variables is described in https://learn.microsoft.com/en-us/cpp/build/building-on-the-command-line?view=msvc-170#path_and_environment, and https://stackoverflow.com/questions/20483619/lib-vs-libpath-environment-variables-difference-for-ms-visual-c-c,

You can choose different triplet, see vckpkg help triplet, but x64-windows-static-md is recommended by vcpkg-rs.

Even the blas-example works with this!

vcpkg would also (presumably) make CMake work on Windows.

Mathieu functions always return zero

The Mathieu functions provided in types::mathieu::MathieuWorkspace always return zero. Example:

use rgsl::types::mathieu::MathieuWorkspace;
use rgsl::Value;

fn main() {
    const Q: f64 = 0.8253525490491695;
    let foo = match MathieuWorkspace::mathieu_Mc(1, 0, Q, 0.5) {
        (Value::Success, res) => res.val,
        _ => panic!("Mathieu function failed"),
    };
    println!("{}", foo);
}

Output: 0. This seems to happen for any input.

By contrast, for a roughly equivalent C program:

#include <stdio.h>
#include "gsl/gsl_sf_mathieu.h"


int main() {
    double q = 0.8253525490491695;
    gsl_sf_result res;
    gsl_sf_mathieu_Mc_e(1, 0, q, 0.5, &res);
    printf("%f", res.val);
}

I get 0.666843.

Windows building instruction missing

I'd like to try this package on windows, but I don't see instruction how to build it...

Deprecated functions in GSL 2.0

Since GSL 2.0 the functions

• gsl_bspline_deriv_alloc
• gsl_bspline_deriv_free
• gsl_sf_legendre_Plm_array
• gsl_sf_legendre_Plm_deriv_array
• gsl_sf_legendre_sphPlm_array
• gsl_sf_legendre_sphPlm_deriv_array
• gsl_sf_legendre_array_size

have been marked deprecated and will be removed in future [1]. Furthermore, gsl's default settings exclude deprecated functions from the build. Thus, linking rgsl against gsl 2.0 or newer is likely to fail, e.g. gsl 2.0+ provided via homebrew on a mac.

[1] http://git.savannah.gnu.org/cgit/gsl.git/tree/NEWS

Failing to compile under Rust 1.51.0

I just updated to the newest version of rustc (1.51.0) and now I cannot build the GSL crate (3.0.0).
I get the following Error:

error: `#[doc(alias = "...")]` is the same as the item's name
   --> /home/yannick/.cargo/registry/src/github.com-1ecc6299db9ec823/GSL-3.0.0/src/stats.rs:150:7
    |
150 | #[doc(alias = "gsl_stats_minmax")]
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^

error: `#[doc(alias = "...")]` is the same as the item's name
   --> /home/yannick/.cargo/registry/src/github.com-1ecc6299db9ec823/GSL-3.0.0/src/stats.rs:170:7
    |
170 | #[doc(alias = "gsl_stats_minmax_index")]
    |       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: aborting due to 2 previous errors

error: could not compile `GSL`

I have the same problem with nightly rust (1.53.0). However reverting back to 1.50.0 (rustup override set 1.50.0) fixes the issue,
though now I cannot use newer rust compilers for my project

Publiciting it on GSL site

Hi there! Thank you for the hard work!!

I noticed that there is no mention of this wrapper in the GSL site, in the section Wrappers for Other Languages (not necessarily complete):.

You might want to rise an issue there to be included.

Cheers!