TL;DR: shared library conflicts are coming soon, to a Julia installation near you. Perhaps only for a short-run engagement.
I don’t know where to file this issue, so I’ll try here.
My immediate problem is in trying to use certain packages together under Julia v0.7-beta. If I load
Gtk, it immediately links to some system libraries, which in turn link to the system installation of
libz.so, which is rather old in my case(s), as it will be for others. Now if I try to load anything with a binary dependence including a more recent
libz, there is a version conflict and the second package fails to load. This is especially likely under v0.7 because FFI packages are adopting a new binary builder infrastructure including such libraries.
This isn’t specific to
libz, but I suspect that
libz will be the apparent culprit for others (although it may hide behind something like
libpng). The issue is related to one reported for
Arpack under v0.7-beta, but (IIUC) more general: this is independent of my compilation environment.
Yes, I can force the load order for interactive work, but not for package testing or other third-party situations. I know about work-arounds like preloading libraries, but they are ugly and we get tired of needing to suggest them to fellow sufferers. (This was a long-standing problem for
PyPlot because until recently Julia itself loaded a system
libz; hence “episode 2” in the title.)
So should packages like
Gtk be “gently persuaded” to convert to the new binary builder system? And even if so, is there any plan to encourage/enforce compatibility between packages here? The current approach does not seem to scale for this (esp. as time goes on). Will we be driven to something like
Conda infrastructure, which is probably nightmarish to maintain (and sometimes, in my experience, to use)?
I hope @staticfloat & friends have figured this all out and can present a reassuring plan, so that this post may just document a temporary pain point.