Hello all. I am probably the oldest community user of GeoLab having used it the past two years to teach the MsPASS short course. Previous work was on the beta version of the system. This past week Earthscope upgraded the setup. In the process it appears they upgraded the unix kernel on which the system runs. Why does that matter? The answer is that some packages like MsPASS depend on compiled libraries that are always subject to becoming stale with a system upgrade. A case in point is I tried to run the MsPASS short course image from last year’s class and got the (to me at least) infamous message:
ImportError: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /opt/conda/lib/python3.11/site-packages/mspasspy/ccore/io.so)
My warning is if you ever get a libc error like this it means one and only one thing: you have to rebuild the image (what you select on the opening page pulldown menu).
Each Environment in GeoLab, including the default “GeoLab” selection, is based on a single container image, each of which is a self contained operating system, libraries and applications. The image building ecosystem, and some care by imager creators, usually results in images that are self-consistent. Each image can have different libraries/applications.
Where we see the kinds of errors you highlight here, is usually when one tries to run pre-compiled binaries in a mismatched container. This is equivalent to taking binaries compiled on one OS to another, it just doesn’t work. The usual solution is to build an image based on one appropriate for the hub (e.g. GeoLab’s default base image) that is self-consistent and runs directly in GeoLab.
Good point, Chad. The key point here, however, is exactly the same container ran a day or two before the new improved GeoLab was rolled out last week. I got the magic name from Sophia and everything I see in it confirms that is true. Your solution is right one. What I need to do is rebuild the container. I need some help to know how to do that as I think Sarah built the MsPASS container for the course last year. Separate topic. For this specific issue it happens, I’m pretty sure, because MsPASS uses unix so files created from compiling C++ with python bindings compiled in with a package called pybind11. Makes the code much much faster but at the cost of creating this kind of problem. The message for the community is this particular problem likely happens only if the package contains compiled code with python bindings.
Fantastic, so far that image seems to function perfectly. It certainly address the libc failure but also I see it has included the new MsPASS features I need for this upcoming course in July. A friendly suggestion is your descriptions of how to do build an image needs some work. I’m a pretty hardy user and could not figure out how to address this. When I review your pull request it looks like you had to so a lot of work to get this to work. Then again, mspass is a more complicated example than most current packages, BUT connecting to services like dask are likely to become very common. I am going to start a new post on that topic as it is a side issue here.