Issue 1:
There is a symbol clash between scipy and libsndfile:

Scipy declares "sf_error" as follow (see https://github.com/scipy/scipy/blob/master/scipy/special/sf_error.h):

void sf_error(const char *func_name, sf_error_t code, const char *fmt, ...);

While libsndfile declare this function as follow (see https://github.com/erikd/libsndfile/blob/master/src/sndfile.c):

int sf_error (SNDFILE *sndfile);

What is the purpose of sf_error in Scipy? It looks like Scipy tries to hack the real "sf_error" function.

Of course having twice the same symbols coming from 2 different libraries create crashes.

Reproducing code example:

An application liked with libsndfile in which we import scipy and then start the unit tests (scipy.test())

Error message:

Crash.

Python version 3.5.2 |Enthought, Inc. (x86_64)| (default, Mar 3 2017, 18:53:01) [GCC 4.4.7 20120313 (Red Hat 4.4.7-17)]
nose version 1.3.7
...............................................................................................................................................................................................F..........................................................................................K.....................................................................................................................................................................................................................................................................................................................................K.............................................................................too many axes: 2 (effrank=2), expected rank=1
too many axes: 2 (effrank=2), expected rank=1
.....K...............F.......................................................................................................................................................................................................................................Segmentation fault (core dumped)

#0 0x000000385ec06f5f in sf_error () from /usr/lib64/libsndfile.so.1
#1 0x00007f3d1c05e6c1 in beta_negint (a=<value optimized out>, b=<value optimized out>) at scipy/special/cephes/beta.c:242
#2 0x00007f3d1c05e62f in cephes_beta (a=<value optimized out>, b=<value optimized out>) at scipy/special/cephes/beta.c:69
#3 0x00007f3d1bfec36d in __pyx_f_5scipy_7special_15orthogonal_eval_binom (__pyx_v_n=<value optimized out>, __pyx_v_k=<value optimized out>)
at scipy/special/_ufuncs.c:31455
#4 0x00007f3d1bfea4d3 in __pyx_f_5scipy_7special_7_ufuncs_loop_d_dd__As_dd_d (__pyx_v_args=<value optimized out>, __pyx_v_dims=<value optimized out>, __pyx_v_steps=
0x3960520, __pyx_v_data=<value optimized out>) at scipy/special/_ufuncs.c:9174
#5 0x00007f3d23f06aeb in iterator_loop (ufunc=<value optimized out>, op=<value optimized out>, dtype=<value optimized out>, order=<value optimized out>,
buffersize=<value optimized out>, arr_prep=0x2, arr_prep_args=0x0, innerloop=0x7f3d1bfea470 <__pyx_f_5scipy_7special_7_ufuncs_loop_d_dd__As_dd_d>, innerloopdata=
0x7f3d1c37b070) at numpy/core/src/umath/ufunc_object.c:1504
#6 0x00007f3d23f0a696 in execute_legacy_ufunc_loop (ufunc=<value optimized out>, args=0x7f3c00000001, kwds=0x2000, op=0x7ffe6653bba0)
at numpy/core/src/umath/ufunc_object.c:1659
#7 PyUFunc_GenericFunction (ufunc=<value optimized out>, args=0x7f3c00000001, kwds=0x2000, op=0x7ffe6653bba0) at numpy/core/src/umath/ufunc_object.c:2625
#8 0x00007f3d23f0aebf in ufunc_generic_call (ufunc=0x2dee040, args=0x7f3cf9d35288, kwds=0x0) at numpy/core/src/umath/ufunc_object.c:4250
#9 0x00007f3d460328b6 in PyObject_Call (func=0x2dee040, arg=<value optimized out>, kw=<value optimized out>) at Objects/abstract.c:2165
#10 0x00007f3d460f3a27 in do_call (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4936
#11 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4732
#12 PyEval_EvalFrameEx (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:3236
#13 0x00007f3d460f5f8e in _PyEval_EvalCodeWithName (_co=<value optimized out>, globals=<value optimized out>, locals=<value optimized out>,
args=<value optimized out>, argcount=1, kws=<value optimized out>, kwcount=0, defs=0x0, defcount=0, kwdefs=0x0, closure=0x0, name=0x7f3cf9fbc9f0, qualname=
0x7f3cf9faef90) at Python/ceval.c:4018
#14 0x00007f3d460f4b9b in fast_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4813
#15 call_function (f=<value optimized out>, throwflag=<value optimized out>) at Python/ceval.c:4730

Scipy/Numpy/Python version information:

SciPy version 0.19.0
Python version 3.5.2

Issue 2:
I was investigating a weird crash that I had in a software that uses SciPy and links to libsndfile.

The backtrace looks like this:

#0 0x00007fffe281936f in sf_error () from /usr/lib/libsndfile.so.1
#1 0x00007fffda890db6 in sf_error_check_fpe (func_name=0x7fffda99a2e5 "expit") at scipy/special/sf_error.c:152

I couldn't see what was wrong for a good hour but the problem is evident: there are two sf_error functions being loaded at the same time:

https://github.com/scipy/scipy/blob/master/scipy/special/sf_error.c#L52

and

https://github.com/erikd/libsndfile/blob/fa1d42fdddcee203c7b0348324f9e657a9eb9c5a/src/sndfile.c#L494

obviously, sf_error_check_fpe calls an unexpected sf_error with a wildly different ABI which leads to such crashes. What would be easy ways to prevent this ?