> We've been providing BRU and BRU Server agents for OpenBSD since > OpenBSD 2.8. > > For the most part, OpenBSD updates have not broken compatibility with > our baseline builds for 2.8 and 3.5 - until 3.9. We have a customer > that has installed 3.9 on a group of servers and we now witness libc > compatibility issues that can't be resolved with a simply symlink.
Sorry, but symlinking shared libraries basically undermines all the reasons why we change the shared library names. We specifically change the shared library major/minor numbers because SEVERE INCOMPATIBILITIES have been introduced, and unlike other projects we do not feel that these incompatibilities should be shoved under the rug and ignored, because random people will later get burned. We introduce the incompatibilities for very strong reasons. The commit messages explain things. > Is it known that applications built against the 3.5 libc are not > compatible with 3.9 (they have been proven to work fine with 3.8)? Yes. I could research the commits done just before each shared library revision crank, and write you specific test programs in about 10 seconds for each case. How will each of those cases affect your application? I don't know. That is why we crank things. > Is > there something that the user can do to enable backwards compatibility, > or is the only solution to compile special versions of the BRU tools > for 3.9? There is no binary backwards compatibility. You have a choice: new or old. Choose. I am sorry, but there is no way we could cope with this any other way as programmers, oh, except for maybe bloating the code every time we need to change something, and 10 years from now libc will be a gig. That's not a world any of us want. Noone wants us to stop improving things.
