----- On 25 May, 2015, at 11:48, René J.V. Bertin [email protected] wrote:
> I don't recall having seen anything about libjpeg and forward compatibility. > It's not surprising that libjpeg.9.dylib cannot be replaced by > libjpeg.8.dylib, > but what about the other way around? (Concretely, what happens with > applications built against libjpeg.8.dylib when that library becomes a symlink > to libjpeg.9.dylib?) There is no such thing as binary compatibility when the library name changes. That's the whole point of changing the library name. If you only add new interfaces and preserve binary compatibility, the library name wouldn't change. You can try it, but if upstream knows what it's doing w.r.t. library version numbering – and it seems that's the case here – all you'll see is a crash or failure to load. Consequently, making libjpeg.8.dylib a symlink to libjpeg.9.dylib is a stupid idea. Don't do it. Btw, your idea of putting library version numbers into package names only makes sense if that gives you the possibility to install different versions of these libraries side-by-side. That, however, is only possible if you split the files installed by these ports into separate packages, such as libjpeg8, libjpeg-dev, etc., because libjpg.dylib -> libjpeg.$num.dylib must be part of a -dev package that is not always installed. That may be an idea worth considering for MacPorts now that we provide a lot of precompiled binaries, but it needs a huge overhaul of our ports tree to work correctly. -- Clemens Lang _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
