math
math copied to clipboard
stan-dev
Allow Math library to link to system-installed libraries/headers
Description
Rather than bundling libraries (e.g., Boost/Eigen) with the Math library, it would be good to add functionality to use the libraries that are already installed on the system.
This will be a first step in packaging cmdstan binaries for linux distros
Current Version:
v4.1.0
It would be great if fixes to those libs are still used, even if the system level libs are to be used.
We currently do no actual fixes in the non-development libraries. For Boost we had the integrate_1d patch that was removed. For Sundials we remove prints for CRAN reasons and I dont think this matters for this use case.
There are a few GTest fixes for MPI, but those are for Math development so also out of scope for Andrew's use case.
Yep pretty much. This is just for the libraries that an end-user would need to compile/run programs, so things like googletest and cpplint aren't all that important
To it's the norm that we need to fix stuff occasionally. I'd much prefer to see this feature support the fix-it thing which we need to do every now and then.
Things like the fixes we do to please CRAN are not needed to take care of, of course.
That's not really something that can be done in a general fashion, since this just takes the system headers and libraries as-is. If we need to patch particular headers, then logic specific to those headers in those libraries would be needed. Similarly if we needed to rebuild system binaries with patches (e.g., libtbb.so or linsundials_cvodes.a), then that also needs to be done on a case-by-case basis.
I think you can achieve this for the header-only things which we use. For the compiled stuff, this is not possible... that's correct. Good point.
EDIT: So for boost we can do this ... and it should be possible.
I am not sure if I understand how do you imagine this.
For example, the last patch for Boost that we had in Math was doing what https://github.com/boostorg/math/pull/455/files does. Are you saying we should fix the system-installed Boost to include this fix for a particular file? That is not something we should be doing imo. Or are you thinking of something else?
No. We are still compiling the things ourselves. So we can control the order of include paths. Hence, we can insert -I flags so that the right boost fix will get into visibility early enough during compilation. This is exactly the same as rstan used to do it. In the setup from rstan we also had to override the R boost install.
Oh, yeah, I guess we could include the patched files with manual flags in that case, like add -I fullpathtofile. That would work I guess yes.
We tried evaluating this earlier in the project (maybe around 2012-2014) and it ended up not being stable for installation. (We being a few of the developers working more on the installation aspect of this.)
It became really hard to debug installation problems and we were running into mismatches of Boost and Eigen... and this was before we introduced the built binaries!
@andrjohns, the makefiles are already set up for this use case if you wanted to do it. If what the top-level description is what you want to accomplish, we can already do that.... I don't know what the requirements are for Linux distros. How do you envision this working in light of a user upgrading their boost or eigen versions or removing it? It seems like the stablest thing to do would be to include a built version inside the Linux distro so it can be linked and stable, but then we're back to compiling the whole thing again. (Maybe it's different, though, because the compiled thing gets stashed somewhere?)
The assumption is that this will be used when the libraries are installed through the system package manager.
For example, the current workflow is:
sudo apt install libboost-math-dev libeigen3-dev \\
libtbb-dev libsundials-dev opencl-headers -y
echo SYS_LIBS=true >> make/local
And then cmdstan/Math can be used as normal, without needing to build Sundials/TBB.
I'm also not tied to this being openly advertised to users, I just need this for packaging cmdstan on linux
Got it.
What happens if / when Sundials/TBB version is changed by the user (or even removed)? Is there some way to check that the installation is in a consistent state?
On Mon, Jun 28, 2021 at 10:23 AM Andrew Johnson @.***> wrote:
I'm also not tied to this being openly advertised to users, I just need this for packaging cmdstan on linux
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/2518#issuecomment-869729307, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADH6F27RIB66N5TNL7HRG3TVCAUHANCNFSM47NGNBXA .
I was approaching this from a packaging perspective, where I would specify version requirements of the dependencies as part of the .deb file. But there is definitely the possibility of a user updating/changing versions and that breaking things. So if this were 'exposed', it would need to be some caveats attached
Thanks for that clarification.
I guess this is where I don't understand the "packaging perspective" -- if it's packaged and installed, but the libraries are required at build and runtime of every new model, how do things like this get packaged?
Stan is different than a lot of things because the Stan programs are built into executables which have these dependencies at the time. And since we're no longer header-only, the linked libraries also need to match. Of course, there's some window of compatibility, but there's always a boundary somewhere.
On Mon, Jun 28, 2021 at 10:37 AM Andrew Johnson @.***> wrote:
I was approaching this from a packaging perspective, where I would specify version requirements of the dependencies as part of the .deb file. But there is definitely the possibility of a user updating/changing versions and that breaking things. So if this were 'exposed', it would need to be some caveats attached
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/stan-dev/math/issues/2518#issuecomment-869740302, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADH6F46QM6IVONOFUORDVDTVCCJNANCNFSM47NGNBXA .
Because the packages can be created with dependencies at minimum (or specific) versions, the package manager will error if a user attempts to upgrade their libraries to an incompatible version (or to remove them).
The issue of users upgrading their libraries after compiling models, causing issues at runtime, are already present - R packages like BH and RcppEigen get updated independently of rstan, and users can download newer versions of cmdstan - so it's not really something unique to this
I guess the only thing to say to users is to - please - only report issues when using our tested combination. Right?
@andrjohns, just thinking ahead and trying to think of ways to make this something ideal...
what if there was a way to check for compatibility? Once these things drift, it's really hard to debug. I'm thinking way back when different versions of Boost would actually cause numerical bugs (not failures) or linked library issues. In an ideal world, we'd not only package this up, but know before running a new model that this will not work -- rather than waiting until we try to run the new model.