On Sep 27, 2017, at 16:24, Ryan Schmidt wrote: > Hello, > > I'm a developer with the MacPorts package management system. > > When built with scons 2.3, the libserf dynamic library on macOS has > current_version and compatibility_version information recorded in it, as it > should: > > $ otool -L opt/local/lib/libserf-1.dylib | head -n 2 > opt/local/lib/libserf-1.dylib: > /opt/local/lib/libserf-1.dylib (compatibility version 1.3.4, current > version 1.3.4) > > When built with scons 2.4.1 or later, it does not: > > $ otool -L opt/local/lib/libserf-1.dylib | head -n 2 > opt/local/lib/libserf-1.dylib: > /opt/local/lib/libserf-1.dylib (compatibility version 0.0.0, current > version 0.0.0) > > We were quite surprised to discover this had occurred, after we rebuilt > libserf due to an openssl upgrade, coincidentally after scons had been > updated. Everything else that used libserf then broke, complaining that it > was trying to load an older version of the library than it had been built > with. > > It is mentioned in the scons change log that InstallVersionedLib, which serf > uses, doesn't honor SHLIBVERSION anymore: > > https://github.com/SConsProject/scons/blob/rel_2.4.1/src/CHANGES.txt#L39 > > I have a fiery passionate hatred for scons (and refer you to the "Please > consider dropping scons" and "I now officially declare myself completely > beaten by scons" threads, and also invite you to ponder the notion that the > developers of scons thought it acceptable to break backward compatibility in > this manner in a bugfix release) and don't wish to try to figure out how to > fix this. Do you have any ideas? > > Here is the MacPorts bug report: > > https://trac.macports.org/ticket/50854
Has anybody had any thoughts on this issue? Is nobody else experiencing this problem? Am I doing something wrong?
