Bug#960893: libc++-10-dev: Can't coinstall multiple libc++-dev versions

[Marc Glisse]

Hello,

just some simple ideas:

1) One way would be to replace the explicit symlinks in
/usr/lib/$triplet with alternatives. For instance, in a postinst.in

update-alternatives --install /usr/lib/@DEB_HOST_MULTIARCH@/libc++.so libc++.so- at DEB_HOST_MULTIARCH@ /usr/lib/llvm- at VERSION_MAJOR@/lib/libc++.so @VERSION_MAJOR@ --slave /usr/lib/@DEB_HOST_MULTIARCH@/libc++.a libc++.a- at DEB_HOST_MULTIARCH@ /usr/lib/llvm- at VERSION_MAJOR@/lib/libc++.a

+ the corresponding remove in prerm.in and corresponding sed line in
rules (see for instance the package "lapack"). And others for
libc++.so.1, libc++abi.so, libc++abi.so.1, maybe more (libomp5?). Using
the major version number as priority makes sense to me, but it could
also be major*100 for regular toolchains and just major for snapshots or
whatever.

2) Imitate gcc, where all the gcc-X packages produce / use libstdc++6
(no version), so we end up with only the most recent one installed.

3) Move the symlinks to the unversioned packages, libc++1-11 would
provide the files in /usr/lib/llvm-11/lib, and libc++1 would provide the
symlink in /usr/lib/$triplet.

And I am sure there are many possible variations, for instance changing 
the granularity of the choice (just a symlink /usr/lib/llvm to 
/usr/lib/llvm-11?)


If we look at the output of clang++ -v when linking, there is
-L/usr/lib/llvm-11/lib, but it comes after -L/usr/lib/$triplet, so even
for ideas 1 and 3 and even for static linking, this would end up linking
with the default version, as if we had gone with idea 2. I don't know if 
that's deliberate or a bug.

-- 
Marc Glisse