Opened 11 years ago

Closed 11 years ago

#40317 closed update (fixed)

stimfit @0.12.4_2: update 0.12.9

Reported by: neurodroid (Christoph Schmidt-Hieber) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: haspatch maintainer Cc: mojca (Mojca Miklavec), cooljeanius (Eric Gallager)
Port: stimfit

Description

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

Attachments (1)

Portfile-stimfit.diff (961 bytes) - added by neurodroid (Christoph Schmidt-Hieber) 11 years ago.
Portfile patch

Download all attachments as: .zip

Change History (23)

Changed 11 years ago by neurodroid (Christoph Schmidt-Hieber)

Attachment: Portfile-stimfit.diff added

Portfile patch

comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)

Keywords: haspatch maintainer added
Summary: Update stimfit to 0.12.8stimfit @0.12.4_2: update 0.12.8
Version: 2.2.0

comment:2 Changed 11 years ago by 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.

comment:3 Changed 11 years ago by mojca (Mojca Miklavec)

Cc: mojca@… added

Cc Me!

comment:4 Changed 11 years ago by neurodroid (Christoph Schmidt-Hieber)

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

comment:5 Changed 11 years ago by mojca (Mojca Miklavec)

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

However I'm getting:

configure: error: Couldn't find lapack.

comment:6 in reply to:  5 Changed 11 years ago by 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.

comment:7 Changed 11 years ago by 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?

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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)

comment:10 Changed 11 years ago by 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).

comment:11 Changed 11 years ago by 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.

comment:12 Changed 11 years ago by 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.

comment:13 Changed 11 years ago by 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.

comment:14 Changed 11 years ago by 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.  */
 

comment:15 Changed 11 years ago by 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.

comment:16 Changed 11 years ago by neurodroid (Christoph Schmidt-Hieber)

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

comment:17 Changed 11 years ago by 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.

comment:18 Changed 11 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: newclosed

comment:20 Changed 11 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: closedreopened
Summary: stimfit @0.12.4_2: update 0.12.8stimfit @0.12.4_2: update 0.12.9

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.

comment:21 Changed 11 years ago by cooljeanius (Eric Gallager)

Cc: egall@… added

Cc Me!

comment:22 Changed 11 years ago by mojca (Mojca Miklavec)

Resolution: fixed
Status: reopenedclosed

Committed in r110733.

Note: See TracTickets for help on using tickets.