linking problem

[Ben Goodrich]

Previously if a Stan program did not use ODEs, it did not matter whether CVODES was linked. But something seems to have changed recently and now rstanarm, which does not currently have any models with ODEs, does not link with the 2.10.0 stuff.

Error in dyn.load(file, DLLpath = DLLpath, ...) :
  unable to load shared object '/tmp/Rtmpm9G9in/Rinst2f355fbfc0d9/rstanarm/libs/rstanarm.so':
  /tmp/Rtmpm9G9in/Rinst2f355fbfc0d9/rstanarm/libs/rstanarm.so: undefined symbol: CVodeSetMaxConvFails
Error: loading failed
Execution halted
ERROR: loading failed

Does anyone have any ideas?

Ben

[Jiqiang Guo]

I suppose the CVODES header files are included somehow.  

Jiqiang 

--
You received this message because you are subscribed to the Google Groups "stan development mailing list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to stan-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Lee]

Yeah, saw the same behavior with pystan. I didn't think we needed it, but there's something subtle going on requiring a cvodes library. 

Suggestions? Is this something we need to back out?

[Ben Goodrich]

On Tuesday, June 14, 2016 at 10:01:22 PM UTC-4, Daniel Lee wrote:

Yeah, saw the same behavior with pystan. I didn't think we needed it, but there's something subtle going on requiring a cvodes library. 

Suggestions? Is this something we need to back out?

I can link rstanarm to the shared object for StanHeaders but it seems like there should be a better solution.

Ben

[Ben Goodrich]

On Tuesday, June 14, 2016 at 10:01:22 PM UTC-4, Daniel Lee wrote:

Yeah, saw the same behavior with pystan. I didn't think we needed it, but there's something subtle going on requiring a cvodes library. 

Suggestions? Is this something we need to back out?

I get these (in addition to a bunch of stuff from the CVODES libaray) from nm

0000000000139540 T stan::math::cvodes_check_flag(int, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
0000000000139630 T stan::math::cvodes_set_options(void*, double, double, long)
0000000000138fb0 T stan::math::free_cvodes_memory(_generic_N_Vector*&, _generic_N_Vector**, void*, unsigned long)

Ben

[Sebastian Weber]

What changed in the meantime is that before these function were part of a templated object. As far as i recall this makes things more header only friendly. However, during the design refactorings this got changed. My guess would be that if we go back to a design where all the cvodes function are part of such an object would solve it ... Or we declare those little functions with "inline" that should do the trick as well if i remember right.

Sebastian

[Daniel Lee]

I didn't think if the inling. I'll give it a try with cmdstan shortly and if it works, I'll submit a pull request on math.

> On Jun 15, 2016, at 1:48 AM, Sebastian Weber <sdw....@gmail.com> wrote:
>
> What changed in the meantime is that before these function were part of a templated object. As far as i recall this makes things more header only friendly. However, during the design refactorings this got changed. My guess would be that if we go back to a design where all the cvodes function are part of such an object would solve it ... Or we declare those little functions with "inline" that should do the trick as well if i remember right.
>
> Sebastian
>

[Bob Carpenter]

Sebastian's right --- we only run into linker problems if
a template is instantiated (or if we have a non-template function,
which is like an instantiation). Otherwise, the compiler only checks
that it's all well-formed syntactically.

One solution would be to write a custom include for all
the linked packages that don't automatically include CVODES.
Or we could break math.hpp into two pieces, math.hpp and
math-cvodes.hpp.

Managing dependencies is always a burden, which is why I'm so
conservative in wanting to add them to Stan.

- Bob