-
-
Notifications
You must be signed in to change notification settings - Fork 5.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
Bump arpack-ng to 3.3.0 #14518
Bump arpack-ng to 3.3.0 #14518
Conversation
Nope, see opencollab/arpack-ng#29. We should just move arpack out to a package to get rid of a fortran build dependency. |
The issue is the lack of autotools? |
Yes. We haven't needed autoconf or automake thus far. Arpack certainly isn't worth adding more build time deps for, unless this fixes any real bugs. |
I think there are some fixes we want, but I will dig deeper.. |
This is the main reason to update arpack. We can just pull in that specific patch too if required. |
In the linked issue they said they might be willing to merge a PR that adds back the autotools files. |
Can we figure out what to do here? |
If we're getting in the habit of re-hosting our own tarballs for upstreams that aren't releasing as often or in the form we want... |
I'd rather do that for now, and get fixes for the known bug in, and then revert to upstream in case they fix it. |
So, fork arpack-ng in JuliaLang, add the autotools, and upload tarball? |
Actually we don't even really need to fork it. Just do like I asked them to do - download their tagged version, run |
I don't have the upload credentials. Is this something you could set up? |
Yes. Can it wait until next week? |
Totally. |
Maybe ask upstream about their release plans first? They seem to be quite responsive. |
Bump. What's the next step? Provide this upstream, and once they merge the PR, use that commit until they make a new release? |
Milan has some good fixes in opencollab/arpack-ng#32 that would likely clean up some messiness in |
Opening a PR makes more sense, I think. |
I went with your idea of just completely ignoring arpack-ng's autotools build system. Had to rename one subroutine that arpack's autotools are skipping to avoid a double definition error, but wasn't too bad. |
Glad that worked out. The SECOND thing has been around forever. Easy fix like you said. |
This could use a few people testing it on Mac, or with ifort, or various other combinations of system blas/lapack etc. Do a |
I have recently started seeing these on os x. Any ideas how to pass the macosx min version flags to gfortran on os x?
|
The arnoldi tests pass on mac. |
Where's that object file from, is it temporary while building arpack with this Line 365 in 636916e
USE_LIBCPP should be getting set on new enough osx versions here Lines 310 to 321 in 636916e
|
I thought we do add the version-min stuff to FC, but gfortran doesn't seem to know about it - perhaps because it is not part of the apple toolchain. |
I find this particular problem fixed if I do:
|
So were the autotools actually doing at least one useful thing and setting that flag or something equivalent? |
So if gfortran (from where, homebrew?) isn't doing the right thing with the |
Why don't we make a tarball including |
This also fixes unrelated issues where libtool fails to link to an external blas library on win64. Should have mentioned that. |
Alright, did that, so this should work the same as the existing arpack version on mac now. It doesn't fix the other issue I was having with libtool refusing to link against a blas dll that doesn't start with "lib" but I found a different workaround for that. (edited a year later - the workaround I found at this time was temporarily making a copy of the blas dll that does start with "lib" just for the purposes of libtool being able to find and link to it, but there's an even better workaround in #21588) |
No description provided.