stimfit @0.12.4_2: update 0.12.9

[neurodroid (Christoph Schmidt-Hieber)]

Portfile patch attached. I'm the maintainer, but I don't have commit rights.

[neurodroid (Christoph Schmidt-Hieber)]

Portfile patch

[mojca (Mojca Miklavec)]

While at it: may the following lines go away?

CC="`${wxWidgets.wxconfig} --cc`" \
CXX="`${wxWidgets.wxconfig} --cxx`" \
LD="`${wxWidgets.wxconfig} --ld`"

Since the port depends on wxWidgets 2.9, I see no reason to change the compiler. The version 2.8 had problems with clang, but 2.9 should be fine with anything.

[mojca (Mojca Miklavec)]

Cc Me!

[neurodroid (Christoph Schmidt-Hieber)]

Yes please, can you just delete these lines or should I attach another patch?

[mojca (Mojca Miklavec)]

I can delete the lines myself, no need for another patch.

However I'm getting:

configure: error: Couldn't find lapack.

[neurodroid (Christoph Schmidt-Hieber)]

Replying to mojca@…:

However I'm getting:

configure: error: Couldn't find lapack.

I was relying on /usr/lib/liblapack.dylib being available on all Macs. Is this not the case? Or is it an architecture problem? I had excluded ppc at some point, but this restriction was removed (not by me) during the recent wxPython-3.0 upgrade.

[mojca (Mojca Miklavec)]

To be more precise:

checking for kernel... checking for fftw_malloc in -lfftw3... yes
checking for dgemm_ in -latlas... no
checking for dgemm_ in -llapack... no
configure: error: Couldn't find lapack.

I do have a symlink

/usr/lib/liblapack.dylib -> ../../System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libLAPACK.dylib

but for some reason it wasn't found and the general policy of MacPorts is to try to be as independent of the system-provided libraries as possible.

I thought that some port was supposed to provide the required libraries. My installation of atlas contains

/opt/local/lib/libatlas.a
/opt/local/lib/liblapack.a

(I don't know why the libraries are static), but the port doesn't seem to be satisfied with those either.

Unrelated: did you even try to play with PortGroup python 1.0 (or python27)?

I have no problem committing the port as-is - it was probably "equally broken" earlier than it is now, but it would be nice to inspect why this happens.

I'm on 10.7. Maybe different OS provides different functions and dgemm_ happens to be absent on mine?

[neurodroid (Christoph Schmidt-Hieber)]

I agree that it would be better to fix this issue before committing.

My suspicion is that you're building a universal binary with powerpc support. System lapack only has i386/x86_64 support. If this is the case, given that there are some more problems with ppc, I'd suggest to re-introduce the architecture restrictions that were removed in r110279.

[mojca (Mojca Miklavec)]

And here's the test from config.log:

#ifdef __cplusplus
extern "C"
#endif
char dgemm_ ();
int
main ()
{
return dgemm_ ();
  ;
  return 0;
}

built with

/usr/bin/clang -o conftest -pipe -Os -arch x86_64 -fPIC   -DWITH_PYTHON -L/opt/local/lib -Wl,-headerpad_max_install_names -headerpad_max_install_names -arch x86_64  conftest.c -llapack

I can reproduce the behaviour in an isolated environment and adding -L/usr/lib doesn't help in any way. Minimal example:

clang conftest.c -llapack
Undefined symbols for architecture x86_64:
  "_dgemm_", referenced from:
      _main in x-NjwmLU.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

[mojca (Mojca Miklavec)]

No, I'm not using anything related to PPC. Lion doesn't even have support for PPC. See the example above.

If stimfit doesn't support universal variant, I can add that back, but this is unrelated. The port already fails under default settings when testing a single architecture. Or is it my machine only?

I'll try to install the old version again to see if I also have problems installing that one. There's a high chance that I already successfully installed the port when testing the wxWidgets changes (even though I skipped testing some of the wxPython ports and I know for some that they are broken).

I see that homebrow provides some openblas libraries (when searching for the error and came across ​https://github.com/staticfloat/homebrew-julia/issues/15).

[neurodroid (Christoph Schmidt-Hieber)]

OK, thanks for looking into this. Maybe there's a problem when MacPorts' lapack (/opt/local/lib/liblapack.a, which I don't have on my system) is installed? I'll try to reproduce this bug, fix it, and then update the Portfile accordingly.

[mojca (Mojca Miklavec)]

It also cannot be related to the lapack in MacPorts because I tried running just clang conftest.c -llapack which shouldn't find the one in MacPorts.

I also tried the previous version and it didn't change anything. Another machine with Lion - no change.

I suspect that lapack in Lion is simply too old.

[neurodroid (Christoph Schmidt-Hieber)]

Thanks again for your time. Not sure what's going on - some users are building on 10.6 without problems. At any rate, I will switch to MacPorts' atlas (which provides lapack) and post an update here as soon as it's ready.

[mojca (Mojca Miklavec)]

However it works with -lblas rather than -llapack (I saw ​some docs suggesting that the function should be part of blas rather than lapack).

After the following change (I made two changes, I'm not sure which made made the difference yet) the configure step succeeds. Again, this doesn't seem to be related to Atlas.

--- a/configure
+++ b/configure
@@ -16248,7 +16248,7 @@ if ${ac_cv_lib_lapack_dgemm_+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
-LIBS="-llapack  $LIBS"
+LIBS="-llapack -lblas  $LIBS"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 
@@ -16299,7 +16299,7 @@ if ${ac_cv_lib_lapack_dgemm_+:} false; then :
   $as_echo_n "(cached) " >&6
 else
   ac_check_lib_save_LIBS=$LIBS
-LIBS="-llapack  $LIBS"
+LIBS="-llapack -lblas $LIBS"
 cat confdefs.h - <<_ACEOF >conftest.$ac_ext
 /* end confdefs.h.  */
 

[mojca (Mojca Miklavec)]

The installation went fine after that. So I can apply the patch and commit and then you can take some time figuring out how exactly the different Mac OS X versions bundle lapack.

The weird thing is also that configure.ac seems to test -lblas later on, but the program never reaches that point and configure throws an error earlier, not giving -lblas a chance.

In the long term I would suggest creating a package for lapack/blas for MacPorts.

In case it's relevant, here are a few warnings:

./abf/axon/AxAbfFio32/abfheadr.cpp:796:24: warning: explicitly assigning a variable of type 'int' to itself [-Wself-assign]
      int pFH = 0; pFH = pFH;
                   ~~~ ^ ~~~
1 warning generated.

In file included from ./gui/doc.cpp:59:
./gui/./doc.h:94:67: warning: private field 'APPeak' is not used [-Wunused-private-field]
        base, APBase, baseSD, threshold, slopeForThreshold, peak, APPeak, tLoReal, tHiReal, t50LeftReal, t50RightReal,
                                                                  ^
./gui/./doc.h:96:23: warning: private field 'APMaxRise' is not used [-Wunused-private-field]
        t50Y, APMaxT, APMaxRise, APMaxRiseT, APt50LeftReal, 
                      ^
2 warnings generated.

In file included from ./gui/childframe.cpp:64:
./gui/./childframe.h:214:17: warning: private field 'pTracesBoxSizer' is not used [-Wunused-private-field]
    wxBoxSizer *pTracesBoxSizer, *pChannelsBoxSizer;
                ^
./gui/./childframe.h:214:35: warning: private field 'pChannelsBoxSizer' is not used [-Wunused-private-field]
    wxBoxSizer *pTracesBoxSizer, *pChannelsBoxSizer;
                                  ^
./gui/./childframe.h:217:10: warning: private field 'firstResize' is not used [-Wunused-private-field]
    bool firstResize;
         ^
3 warnings generated.

In file included from ./gui/dlgs/smalldlgs.cpp:16:
./gui/dlgs/./smalldlgs.h:666:22: warning: private field 'm_srcDirPicker' is not used [-Wunused-private-field]
    wxDirPickerCtrl *m_srcDirPicker,*m_destDirPicker;
                     ^
./gui/dlgs/./smalldlgs.h:666:38: warning: private field 'm_destDirPicker' is not used [-Wunused-private-field]
    wxDirPickerCtrl *m_srcDirPicker,*m_destDirPicker;
                                     ^
./gui/dlgs/./smalldlgs.h:667:17: warning: private field 'm_textCtrlSrcFilter' is not used [-Wunused-private-field]
    wxTextCtrl *m_textCtrlSrcFilter;
                ^
3 warnings generated.

In file included from ./pystf.cxx:66:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:15:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1728:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
 ^
In file included from ./pystf_wrap.cxx:3077:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/arrayobject.h:15:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarrayobject.h:17:
In file included from /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/ndarraytypes.h:1728:
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/numpy/core/include/numpy/npy_deprecated_api.h:11:2: warning: "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-W#warnings]
#warning "Using deprecated NumPy API, disable it by #defining NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION"
 ^
1 warning generated.

[neurodroid (Christoph Schmidt-Hieber)]

OK, thanks. I can reproduce the bug now that I have MacPorts' atlas installed. Will fix this now.

[mojca (Mojca Miklavec)]

r110527. The buildbots succeed. Weird enough the configure step already succeeded at

checking for dgemm_ in -latlas... yes

We can definitely discuss about a better/cleaner solution for the next release. And I still don't understand what is wrong with both of my machines.

[neurodroid (Christoph Schmidt-Hieber)]

I've ​added a configure option to provide a custom LAPACK library and ​added a variant to use MacPorts atlas instead of system LAPACK. The updated Portfile is available here: ​https://stimfit.googlecode.com/git/macosx/macports/science/stimfit/Portfile

Should I submit a new ticket?

[mojca (Mojca Miklavec)]

Next time please write something like "see also #40318". I didn't notice your other request until now when you pointed me to your original sources. There are way too many tickets and commits and I only had stimfit on my radar due to its dependency on wxWidgets.

I have a few question about this change (I would really like to understand why 0.12.8 failed to work on my computer), but I'm too tired to think at the moment, so it's better to take some rest before I do/commit something stupid.

[cooljeanius (Eric Gallager)]

Cc Me!

[mojca (Mojca Miklavec)]

Committed in r110733.