Allow Math library to link to system-installed libraries/headers

[andrjohns]

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

[wds15]

It would be great if fixes to those libs are still used, even if the system level libs are to be used.

[rok-cesnovar]

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.

[andrjohns]

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

[wds15]

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.

[andrjohns]

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.

[wds15]

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.

[rok-cesnovar]

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?

[wds15]

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.

[rok-cesnovar]

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.

[syclik]

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?)

[andrjohns]

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.

[andrjohns]

I'm also not tied to this being openly advertised to users, I just need this for packaging cmdstan on linux

[syclik]

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 <#2518 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AADH6F27RIB66N5TNL7HRG3TVCAUHANCNFSM47NGNBXA> .

[andrjohns]

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