Christian Weisgerber <[email protected]> wrote: > Mark Kettenis: > > > As we discussed some time ago, adding symlinks like > > > > libfoo.so -> libfoo.so.x.y > > > > brings us more in line with other ELF platforms and will allow us to > > drop some OpenBSD-specific code from our linkers. It also makes it > > possible for developers to easily revert a library version bump. > > That's base. What are we going to do for ports? > > It's not clear to me how the accumulated twenty years of autoconf > versions etc. are going to react to this.
I've expressed my doubt for how making this in base will affect ports. I think someting will see the *.so short-form, and assume that's the final word, and load that specific file rather than use the default ldconfig/ld.so mapping. ld.so understands libfoo.so means "get the right version", kind of. But do all things understand that... or are there runtime pieces of software that try *.so first, then only try *.so.#.# after failing? Noone else cranks ABI versions like we do. glibc hasn't cranked their numbers in 20 years. At this point, perhaps being different in this regard is a strength since it makes people THINK, whereas adding this symbolic link may cause transitions to not work. Let me give an example of a problem. You do a make build, through a major ABI break. Now you have libfoo.so pointing at new libraries. But you have a browers on your system, which you need to use to refresh a captive portal. Can the browser start after this ABI crossing? Does the browsers load the SO files it was linked against, or does it follow the symbolic link to a file which is incompatible (imagine like during the time_t change, where struct stat changed). At this point, 50% of you say ld.so will just work. But the other 50% of you know that chrome is a shell-script which has shared library awareness, and the next-level binaries are thin veneers over shared library loading using dlopen, and library names are being mangled at runtime resolution.. So will they work over an ABI crank? I'm saying I don't know. The problem is Linux never makes such ABI cranks. Our major.minor encoding forces awareness through every stage of the link/resolve process, and adding these symbolic links undoes that awareness by pointing at a specific file for ld's convenience, but potentially misleading front-end code before dlopen(). The proposed change solves a problem in ld, but does it open a can of worms in ld.so / dlopen?
