Linking or not linking against libpython

[StephenSmith25]

Hey,

I was reading the issue #128 and have a few thoughts / uncertainties. I see the explicit link to the python library was removed in #187. This removes any issues running the FMU inside a python interpreter (e.g. fmpy). However, if I was going to run it from C/C++ code with,

void *libraryHandle = dlopen("binaries/linux64/Resistor.so");

I would now get an error

Error: binaries/linux64/Resistor.so: undefined symbol: _Py_NoneStruct

As the dynamic linker no longer resolves the symbols. To fix this issue I would need to load the python library prior to the FMU,

void *pythonHandle = dlopen("libpython3.so", RTLD_GLOBAL | RTLD_NOW);

Which is fine. Just unsure whether other environments (matlab ect) can cope with this change.

It seems there are two competing use cases here, either,

1. The FMU is imported by a python tool (e.g. fmpy) so the symbols are already resolved. In this case the pythonfmu-export should not link to the python libraries.

or

2. The FMU is not imported within a python environment. In which case the python symbols need to be available when we load the FMU. Therefore it probably makes sense to link to the python library (and treat it as a tool which embeds python?)

I think supporting 1) probably makes the most sense, but if you are in case 2) you may need to manually load libpython if it has not already been loaded?

Maybe I am completely off with all of this, I am just working on a fork of this to support FMI3 so I am having the same concerns as #128 and #187.

(my experiences/statements are all based on Linux use)

[markaren]

Thanks for the valuable input. To be honest, I'm happy as long as it works on Windows, so it's good that we have some voices discussing how linux should be solved.

Another issue with 2) is that it expects a specific version of Python, which is cumbersome.

In my perfect world, everyone builds their preferred version from source :)

[StephenSmith25]

Thanks for the input! I also prefer building from source; it simplifies everything, and users can consume it as they wish. Just a potential pitfall for those relying on the packaged version and not using python: there might be a need to manually load Python. However, this was probably already necessary if they were loading the FMU with RTLD_LOCAL on Linux (which likely relates to #152).