>However, to ease this transition, change ld.so to only load the first libc >version that we encounter (in a breadth first sense) and substitute that >libc version for all further loads of libc, even if different versions are >requested. This is done silently since I can't come up with a good warning >message. In practice this means the libc version requested by the >executable itself will be loaded. This means that shared libraries may >fail to load if they use a symbol that has been removed. But given the >constraints, this is the best that we can do. Even when we bump the >libc major, the set of changes is typically small and most binaries and >shared libraries will continue to run and allow the user to run pkg_add -u >without any fallout.
When there are API additions and deletions, we tend to be pretty careful. Meaning, additions tend to happen well in advance of deletions. I've done a vague retrospective inspection of this, and it looks like we would not have been negatively affected in the last 4 years, during a 6-month window. Maybe we can be more careful. Generally, anyone doing a development that will remove an API is going to hit the issue first by themselves. And I think it will be more a more obvious failure for that developer now, than it was in the past. So this behaviour is probably an improvement.
