Bug#960893: libc++-10-dev: Can't coinstall multiple libc++-dev versions
Marc Glisse
marc.glisse at inria.fr
Sun Mar 28 22:43:48 BST 2021
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
More information about the Pkg-llvm-team
mailing list