Limited support for stand-alone clients on Linux/macOS

[john-hen]

MPh 0.8.0, released today, adds support for Linux. That support is slightly limited in that it does not fully work out of the box. In order to start a stand-alone client (as opposed to running the Comsol session in client-server mode), it requires the user take an extra step and configure the search path for shared libraries as described in the documentation.

This is fine, but not ideal. For one thing, it's not just pip install and be done with it. And for another, it prevents users from easily selecting a specific Comsol version as the computation back-end, which is sometimes useful when reproducing earlier simulation results. So ideally, the manual configuration would not be necessary, but instead be done from Python code.

To perhaps track progress on this, or discuss a possible solution, here are some additional details. MPh now follows the instructions exactly as given in Comsol's Programming Manual (specifically, on pages 23 and 916) for running Java applications from the Eclipse IDE. That is, it sets up the environment in that same way before "initializing" the "stand-alone" client. (As opposed to a client-server connection, which works anyway, without any additional configuration.)

However, that alone does not do it. While all appears to be in working order as far as the Java Virtual Machine is concerned, in that it is aware of the locations of the external (native) libraries, these libraries themselves, which are dynamically loaded, have trouble finding each other, leading to a java.lang.UnsatisfiedLinkError. Which is odd: One would think that these child processes inherit the environment set up in the parent process.

To showcase all of this, I have added the demo script test_Linux to the sandbox branch.

[john-hen]

So as it turns out, this is a fundamental issue with Unix-like operating systems — Linux same as macOS. I don't think it will ever be resolved in the way I was hoping.

The problem starts with the fact that relying on LD_LIBRARY_PATH is bad and was originally meant as a handy tool for developers, not a means to deploying applications to end users. And yet many software companies do just that, to have their executables find their very own shared libraries, even though there are better ways to accomplish the same thing.

Comsol is just one example of many. Such as Firefox and Chrome/Chromium were, until they fixed that. Whereas on Windows the Comsol executable is a binary file, comsol.exe, on Linux it's a shell script, hundreds of lines long, that, among many other things, sets LD_LIBRARY_PATH, only to then start the actual application. This is a common work-around if you don't include custom search paths in the binaries at build time.

The problem is exacerbated by the fact that the system function that loads external shared libraries on Linux, dlopen(), only ever checks LD_LIBRARY_PATH once when a process starts, but then never looks back. So the loader won't notice any changes to that environment variable by the time Python is running. Changing it has no effect on the current process.

This explains why the script test_Linux fails to run. Unless, of course, we export LD_LIBRARY_PATH in the shell before starting the script, or, alternatively, run the script as a subprocess after setting os.environ['LD_LIBRARY_PATH'] in a Python wrapper. Neither one of which is an out-of-the-box solution.

Commonly suggested work-arounds are re-starting the original Python process via os.execv() (which… just no) or trying to preload any and all .so files up front via ctypes.CDLL() (which fails here because they are all interdependent).

Microsoft, for once, got this right. On Windows, the library loader does heed live changes to the search path, which is just PATH in that case.

[john-hen]

MPh 0.9.0, released today, provides the new convenience function mph.start() which works around the issue described here. On Windows, it starts a stand-alone client. On Linux and macOS, it uses client–server mode to create the local session. More details in the documentation chapter "Limitations".