Skip to content
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

Closed
staticfloat opened this issue Oct 12, 2012 · 7 comments
Closed

dgesdd not exported in v0.2.4 on OSX #147

staticfloat opened this issue Oct 12, 2012 · 7 comments
Milestone

Comments

@staticfloat
Copy link
Contributor

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:

$ nm libopenblas_penrynp-r0.2.3.dylib | grep dgesdd
0000000000929430 T _LAPACKE_dgesdd
00000000009295f0 T _LAPACKE_dgesdd_work
0000000000578f30 T _dgesdd_

But now with v0.2.4, I get:

$ nm libopenblas_penrynp-r0.2.4.dylib | grep dgesdd
00000000009313b0 T _LAPACKE_dgesdd
0000000000931570 T _LAPACKE_dgesdd_work
000000000057a870 t _dgesdd_

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.

@StefanKarpinski
Copy link
Contributor

Thanks for filing this and looking into it.

@zchothia
Copy link
Contributor

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.

@staticfloat
Copy link
Contributor Author

Perhaps this is a problem with LAPACK?
On Oct 12, 2012 1:59 PM, "zchothia" notifications@github.com wrote:

Interesting - a bisect session seems to point at 08c177chttps://github.com/xianyi/OpenBLAS/commit/08c177ca36as 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.


Reply to this email directly or view it on GitHubhttps://github.com//issues/147#issuecomment-9390108.

@zchothia
Copy link
Contributor

I have fixed this on the develop branch. It turns out we weren't exporting the symbols for the new LAPACK version.

@staticfloat
Copy link
Contributor Author

Great. We'll just hold off on moving to 0.2.4 until that gets merged into a
stable branch then!

Thanks for the quick fix!
On Oct 12, 2012 3:01 PM, "zchothia" notifications@github.com wrote:

I have fixed this on the develop branch. It turns out we weren't exporting
the symbols for the new LAPACK version.


Reply to this email directly or view it on GitHubhttps://github.com//issues/147#issuecomment-9393005.

@ViralBShah
Copy link
Contributor

Fantastic. We'll just wait for 0.2.5. There is no hurry to use 0.2.4 for julia.

@xianyi
Copy link
Collaborator

xianyi commented Oct 13, 2012

Thank @zchothia for your patch.

I forgot it. :(

Xianyi

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants