George Koehler <kern...@gmail.com> wrote: > On Tue, 11 Feb 2020 18:58:48 +0100 > Jeremie Courreges-Anglas <j...@wxcvbn.org> wrote: > > > So the steps would be: > > - build and install a new clang > > - bump the major of libc++, build and install it > > - rebuild and reinstall clang > > - build new snap > > You are the first person to suggest bumping .so majors; I didn't think > to do so. If libc++ needs a major bump, then libc++abi and libLLVM > might also need them. These 3 are the only .so (that I can find) > built by base-clang on powerpc. > > Across base + xenocara + ports, almost nothing uses these 3 .so on > powerpc. The only users that I find are > - /usr/bin/clang* using libc++.so.3.0 and libc++abi.so.1.0 > - nothing using libLLVM.so.1.0 > > (xenocara/lib/mesa uses libLLVM only for i386 amd64 arm64. I looked > for ports with LLVM in WANTLIB, found only devel/py-llvmlite, but it > requires base-clang, and ports doesn't use base-clang for powerpc.) > > If we don't bump majors, then people who upgrade OpenBSD macppc would > get the new libc++.so.3.0 and libc++abi.so.1.0 at the same time as the > new clang; and people on other platforms won't see an unnecessary > major bump. > > If we do bump majors, then people who had used /usr/bin/clang++ on > OpenBSD macppc might be able to run their old binaries with the old > libc++.so.3.0 and libc++abi.so.1.0, while the new clang would use > libc++.so.4.0 and libc++abi.so.2.0.
We always bump minors or majors when the ABI changes (depends which kind of ABI changes, but majors are common). We never sneak in a ABI change. You are changing the ABI. There's only one way this goes.. Yes the files change on all architectures. There's nothing wrong with that. As long as it can build through..
