sundials2 @2.7.0: Symbol not found: _klu_solve

[jantheron]

cantera fails upon importing to python27 with the following message

>>> import cantera as ct
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cantera/__init__.py", line 4, in <module>
    from ._cantera import *
ImportError: dlopen(/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/cantera/_cantera.so, 2): Symbol not found: _klu_solve
  Referenced from: /opt/local/lib/libsundials_cvodes.2.dylib
  Expected in: flat namespace
 in /opt/local/lib/libsundials_cvodes.2.dylib

[ryandesign (Ryan Carsten Schmidt)]

For future reference, into the Cc field, you should place the maintainer's email address or GitHub handle. You can find this information by running the command port info --maintainers [portname]. Don't literally paste that command into the Cc field. Also, remember to use WikiFormatting when writing in Trac.

Since the unknown symbol was referenced from a sundials2 library, I think this is probably a bug in the sundials2 port rather than the cantera port. The cantera source code does not contain the string klu_solve but the sundials2 source code does.

I don't know if it has any bearing on the problem, but I'm suspicious of the use of the flat namespace, which has not been recommended for over a decade. I don't yet see where in the build system the flat namespace is being requested.

I notice that the sundials libraries are being built with -undefined dynamic_lookup, which means that if there are any undefined symbols at build time, it doesn't complain about them, assuming that they will exist at runtime; in the case of klu_solve at least, that's apparently not happening. If I remove that flag from the build, then the build fails with undefined symbols errors, not unsurprisingly.

[jantheron]

Should I file a bug for the sundials2 port in that case, or what course of action do you recommend?