ABI compatibility and platform-native shared library versioning; Linux vs. Mac OS

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

ABI compatibility and platform-native shared library versioning; Linux vs. Mac OS

Boost - Build mailing list
Hi,

I work on an experimental MacPorts clone that also supports Linux and ran into an ABI compatibility issue upgrading my Boost "port" from 1.59 (Linux) or 1.66 (Mac) to 1.71 .

On both platforms, existing executables failed to load because of missing symbols in libboost_system_mt. On Linux it was quite easy to work around having to rebuild all dependents because the Boost libraries are versioned as usual on the platform, i.e. the existing dependency are on libboost*.so.1.59.0 (not on libboost*.so.1, surprisingly and fortunately). Preserve the old *runtime* libraries and existing executables will continue to run; new builds will link to libboost*.so which point to and will make them depend on libboost*.so.1.71.0.

Annoyingly, the Mac build does NOT create shared libraries that are versioned according to the platform norm for POSIX-style shared libraries, that is, they don't follow

libboost_x_y.dylib -> [libboost_x_y.MAJOR.dylib ->] libboost_x_y.MAJOR.MINOR.patch.dylib

and a workaround that preserves the old *runtime* libraries is thus not possible. Most of the dependents that fail to load against the new libraries are from huge packages that would take hours to rebuild, so it's worth investigating the issue...

Two questions:

- is it to be expected that 1.7x breaks ABI compatibility with 1.5x and 1.6x?
- is there a toolchain that I can select at "configure" (bootstrap) time to get the kind of libraries I want, or alternatively, which files would I tweak and how? I looked over relevant Mac/Linux differences in the build scripts but haven't found anything yet.

Supplementary question: the existing "port" I work with mentions that using ccache to build boost can lead to subtle ABI issues. Is that a stale warning or is it still the case? It should speed up rebuilds that differ only in the way libraries are named...


NB: using symlinked linker-interface libraries libboost_x_y.{dylib,so} which point to the appropriate runtime libraries will ensure that existing build systems continue to work as you'd expect, which does not appear to be the case when I build with layout=versioned instead of layout=tagged.

Thanks in advance,
R.
_______________________________________________
Unsubscribe & other changes: https://lists.boost.org/mailman/listinfo.cgi/boost-build