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)
Change History (23)
Changed 11 years ago by neurodroid (Christoph Schmidt-Hieber)
Attachment: | Portfile-stimfit.diff added |
---|
comment:1 Changed 11 years ago by larryv (Lawrence Velázquez)
Keywords: | haspatch maintainer added |
---|---|
Summary: | Update stimfit to 0.12.8 → stimfit @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: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 follow-up: 6 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 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: | new → closed |
comment:19 Changed 11 years ago by 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?
comment:20 Changed 11 years ago by mojca (Mojca Miklavec)
Resolution: | fixed |
---|---|
Status: | closed → reopened |
Summary: | stimfit @0.12.4_2: update 0.12.8 → stimfit @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:22 Changed 11 years ago by mojca (Mojca Miklavec)
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Committed in r110733.
Portfile patch