Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

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

175 views
Skip to first unread message

Witold Baryluk

unread,
May 17, 2020, 7:40:03 PM5/17/20
to
Package: libc++-10-dev
Version: 1:10.0.0-4
Severity: normal


It is not the end of the world, but it does impose some limitations:

# apt install libc++-dev
The following additional packages will be installed:
libc++-9-dev libc++1-9 libc++abi1-9
Suggested packages:
clang
The following packages will be REMOVED:
libc++-10-dev libc++1-10 libc++abi-10-dev libc++abi1-10
The following NEW packages will be installed:
libc++-9-dev libc++-dev libc++1-9 libc++abi1-9
#

The headers are already in versioned locations, and clang from what I have seen with clang:

$ clang++-10 -v -march=native -O3 -fcoroutines-ts -std=c++2a -stdlib=libc++ -lc++abi nanotest.cpp -o nanotest
clang version 10.0.0-4
ignoring nonexistent directory "/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/llvm-10/bin/../include/c++/v1
/usr/local/include
/usr/lib/llvm-10/lib/clang/10.0.0/include
/usr/include/x86_64-linux-gnu
/usr/include
...
$


$ dpkg -L libc++-10-dev:amd64 | grep include | head
/usr/lib/llvm-10/include
/usr/lib/llvm-10/include/c++
/usr/lib/llvm-10/include/c++/v1
/usr/lib/llvm-10/include/c++/v1/__bit_reference
/usr/lib/llvm-10/include/c++/v1/__bsd_locale_defaults.h
/usr/lib/llvm-10/include/c++/v1/__bsd_locale_fallbacks.h
/usr/lib/llvm-10/include/c++/v1/__config
/usr/lib/llvm-10/include/c++/v1/__cxxabi_config.h
/usr/lib/llvm-10/include/c++/v1/__debug
/usr/lib/llvm-10/include/c++/v1/__errc
...
/usr/lib/llvm-10/lib
/usr/lib/llvm-10/lib/libc++.a
/usr/lib/llvm-10/lib/libc++.so
...
$

So I would assume it it should be easily possible, and clang already
default to correct includes. I do not know if it also defaults to the
correct linker paths tho. Because packages do have libc++.so symlinks,
that can throw it off, unless user manually select what they want:


$ dpkg -L libc++-10-dev:amd64 | grep usr/lib/x86.*/libc++.*
/usr/lib/x86_64-linux-gnu/libc++.a
/usr/lib/x86_64-linux-gnu/libc++.so
$

$ ls -lh /usr/lib/x86_64-linux-gnu/libc++.*
lrwxrwxrwx 1 root root 23 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.a -> ../llvm-10/lib/libc++.a
lrwxrwxrwx 1 root root 24 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so -> ../llvm-10/lib/libc++.so
lrwxrwxrwx 1 root root 13 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so.1 -> libc++.so.1.0
lrwxrwxrwx 1 root root 28 Apr 10 08:27 /usr/lib/x86_64-linux-gnu/libc++.so.1.0 -> ../llvm-10/lib/libc++.so.1.0
$

But that seems easily fixable.




-- System Information:
Debian Release: bullseye/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental-debug'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 5.2.0-3-amd64 (SMP w/32 CPU cores)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc++-10-dev depends on:
ii libc++1-10 1:10.0.0-4

libc++-10-dev recommends no packages.

libc++-10-dev suggests no packages.

-- no debconf information

Marc Glisse

unread,
Mar 28, 2021, 6:00:03 PM3/28/21
to
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-@DEB_HOST_MULTIARCH@ /usr/lib/llvm-@VERSION_MAJOR@/lib/libc++.so @VERSION_MAJOR@ --slave /usr/lib/@DEB_HOST_MULTIARCH@/libc++.a libc++.a-@DEB_HOST_MULTIARCH@ /usr/lib/llvm-@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
0 new messages