> On Aug 4, 2016, at 10:06 PM, Julian Elischer <jul...@freebsd.org> wrote: > > personally I'd rather we drove a stake through the heart of symbol versioning > and > went back to how it was, when one could work out what was going on. > I certainly miss the ability to get the openssl package to overwrite the base > one, > which I'm told is no longer possible due to versioning.
That seems unlikely to be a strategy for long-term success given all of the opportunities for *unintentional* overwriting of symbols. In other words, it’s great when it works for you. It sucks when it works against you. That said, in OS X, Solaris-style symbol versioning didn’t really yield a lot of dividends and turned out to be a far-too-granular way of permuting APIs over time. What tended to happen instead was that symbols got renamed through header hacks (“aliasing”) and the old binaries simply continued to work by calling different versions of function X (newly compiled applications talking to the new implementation). What HAS yielded a lot of dividends in OS X is a two-level namespace for all symbols. To quote the Apple docs: "The two-level namespace feature of OS X v10.1 and later adds the module name as part of the symbol name of the symbols defined within it. This approach ensures a module’s symbol names don’t conflict with the names used in other modules.” This prevents other problems and allows you to move symbols around en-masse in refactoring exercises rather than having to version them. If FreeBSD is genuinely “fed up” with ELF symbol versioning, I might suggest that other alternatives be explored rather than simply going back to the Bad Old Days because they were more predictable. - Jordan _______________________________________________ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
