-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
dgesdd not exported in v0.2.4 on OSX #147
Comments
Thanks for filing this and looking into it. |
Interesting - a bisect session seems to point at 08c177c as the first bad revision. This was when we upgraded from LAPACK 3.4.1 to 3.4.2. This should just be a bug-fix release and a quick glance doesn't seem to indicate any change in how the code is built. |
Perhaps this is a problem with LAPACK?
|
I have fixed this on the develop branch. It turns out we weren't exporting the symbols for the new LAPACK version. |
Great. We'll just hold off on moving to 0.2.4 until that gets merged into a Thanks for the quick fix!
|
Fantastic. We'll just wait for 0.2.5. There is no hurry to use 0.2.4 for julia. |
Thank @zchothia for your patch. I forgot it. :( Xianyi |
Hey there @xianyi,
The Julia dev team just noticed that OpenBLAS v0.2.4 doesn't seem to export
dgesdd_
in the same way as it used to. With v0.2.3, I used to get:But now with v0.2.4, I get:
Note that the lowecase
t
before_dgesdd_
in the v0.2.4 output means that_dgesdd_
is a local, not global symbol, and thus I don't think we can dynamically link to it. I took a look at the source differences between v0.2.3 and v0.2.4, but I can't really figure out why this is happening. Also, this issue seems to be related to the OSX platform; Ubuntu machines seem to be able to dynamically link to_dgesdd_
just fine.The text was updated successfully, but these errors were encountered: