-
Notifications
You must be signed in to change notification settings - Fork 570
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
New Recipe: qdldl v0.1.5 #4323
New Recipe: qdldl v0.1.5 #4323
Conversation
Q/qdldl/build_tarballs.jl
Outdated
LibraryProduct("libqdldl", :libqdldl64, "double/lib"), | ||
LibraryProduct("libqdldl", :libqdldl32, "single/lib") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unfortunately it isn't a good idea to have two libraries with same soname in the same process. It's hugely problematic: #3801
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@imciner2 you seem to be familiar with this library. Is there a way to build the two distinct variants next to each other with different sonames by default? This is what FFTW does, which makes it possible for different variants to coexist, but having same soname only causes problems.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Bummer. I'll see if I can get the authors to provide an option to add a suffix to the library name.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The short answer is no, there is no way to build the two variants next to each other right now, and I don't think any other consumer of QDLDL has ever wanted to provide both a float32 and float64 variant, they usually have just used float64 if they provide a library (or at least no one has reached out to us about it). Is there a real need to provide float32 in the C library when there is QDLDL.jl that can handle any type under AbstractFloat
since it is a pure Julia implementation?
I've modified this so that it only exports one library for now. I'll see if I can find a way to get add the single-precision library down the road. |
I renamed the project to match the name used in the README. Thanks for your contribution! BTW, I noticed there is a pure-julia implementation at https://github.com/osqp/QDLDL.jl 🙂 |
Unfortunately the pure Julia version doesn't seem to be very actively maintained right now. The Julia version is actually faster, as well! |
Not all packages will have constant commits, so I don't know why you claim it isn't actively maintained. There are no open issues and the only 2 open PRs were opened within the last month - during which there has been a major holiday season. |
* New Recipe: qdldl v0.1.5 * Build only Float64 for now * [QDLDL] Rename from `qdldl` to match styling of upstream project Co-authored-by: Mosè Giordano <mose@gnu.org>
This is for the qdldl library for solving quasidefinite symmetric systems.
Provides support for both
Float32
andFloat64
types, available as separate shared libraries.