Make linux.yaml workflow work for debian:testing/clang

[dgreatwood]

Intermittently, debian:testing has been failing with clang, saying that libstdc++ cannot be found. In debian:testing/clang, normally libstdc++-dev is installed as a dependency of meson. In the situation where the build breaks, the meson dependency is different to the latest available libstdc++; for instance, installing meson dependencies might install libstdc++-13-dev, whereas apt has access to libstdc++-14-dev. In other situations, the meson dependency libstdc++-..-dev may be the same as the latest libstdc++-..-dev to which apt has access.

To prevent the build breaking, we need to install the latest libstdc++-..-dev to which apt has access - not just the N-1 libstdc++-..-dev version which may be installed as a meson dependency. We do this now in linux.yaml.

[Tachi107]

Are you sure libstdc++-dev gets pulled in by meson? I don't see it in its dependencies. Have you tried explicitly installing libstdc++-dev manually?

[dgreatwood]

Are you sure libstdc++-dev gets pulled in by meson? I don't see it in its dependencies.

[DG] Yes. For instance, look at this run: https://github.com/pistacheio/pistache/actions/runs/11378236269/job/31653690670 Under "Install dependencies (Debian)", line 93, you can see it installing "libstdc++-13-dev" as a dependency.

Have you tried explicitly installing libstdc++-dev manually?

[DG] Yes, it doesn't help unfortunately, unless you make the version explicit (i.e. you manually install libstdc++-14-dev).

…

On Wed, Oct 16, 2024 at 10:00 PM Andrea Pappacoda ***@***.***> wrote: Are you sure libstdc++-dev gets pulled in by meson? I don't see it in its dependencies. Have you tried explicitly installing libstdc++-dev manually? — Reply to this email directly, view it on GitHub <#1256 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFMA24A27XBUXP7XVDZGJDZ34775AVCNFSM6AAAAABQC2NHKWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMJYGUYDENBZGU> . You are receiving this because you were assigned.Message ID: ***@***.***>

-- NOTICE: This email and its attachments may contain privileged and confidential information, only for the viewing and use of the intended recipient. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, acting upon, or use of the information contained in this email and its attachments is strictly prohibited and that this email and its attachments must be immediately returned to the sender and deleted from your system. If you received this email erroneously, please notify the sender immediately.  Xage Security, Inc. and its affiliates will never request personal information (e.g., passwords, Social Security numbers) via email.  Report suspicious emails to ***@***.*** ***@***.***>

[Tachi107]

For instance, look at this run: https://github.com/pistacheio/pistache/actions/runs/11378236269/job/31653690670 Under "Install dependencies (Debian)", line 93, you can see it installing "libstdc++-13-dev" as a dependency.

Yeah, but we do not only install the Meson package :) Most likely, in this case, libstdc++-13-dev is installed as a dependency of the clang package: $ apt depends clang clang Depends: clang-16 (>= 16~) $ apt depends clang-16 clang-16 Depends: libc6 (>= 2.34) Depends: libclang-cpp16t64 (>= 1:16.0.6) Depends: libllvm16t64 Depends: libstdc++6 (>= 11) Depends: libstdc++-13-dev <--------- Depends: libgcc-13-dev Depends: libobjc-13-dev Depends: libclang-common-16-dev (= 1:16.0.6-27+b1) Depends: llvm-16-linker-tools (= 1:16.0.6-27+b1) Depends: libclang1-16t64 (= 1:16.0.6-27+b1) Depends: libc6-dev Depends: binutils

> Have you tried explicitly installing libstdc++-dev manually? [DG] Yes, it doesn't help unfortunately, unless you make the version explicit (i.e. you manually install libstdc++-14-dev).

I have found the underlying issue. Clang tries to use libstdc++14 instead of the already installed libstdc++13 because out CI job always installs the "gcc" package which in turns pulls in libgcc-14-dev, which creates the /usr/lib/gcc/x86_64-linux-gnu/14 directory. At this stage, the directory only contains C includes and libraries, not C++ ones, as the C++ ones reside in the same directory but get installed by the libstdc++-14-dev package. So we can either: 1. Stop installing the gcc package when using clang 2. Install the libstdc++-N-dev corresponding to the default gcc version Your current workaround works but might break in the scenario where the default gcc depends on e.g. libstdc++-14-dev but libstdc++-15-dev becomes available, as that would get installed instead. I propose trying to adopt solution 1., which seems cleaner in my opinion. Here's an example clang invocation which demonstrates the current issue on my Debian Testing system: $ clang++ -fuse-ld=lld -v main.cpp Debian clang version 16.0.6 (27+b1) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/13 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/14 [...] ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/x86_64-linux-gnu" ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/backward" ignoring nonexistent directory "/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../x86_64-linux-gnu/include" ignoring nonexistent directory "/include" [...] "/usr/bin/ld.lld" -pie --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /lib/x86_64-linux-gnu/Scrt1.o /lib/x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/14/crtbeginS.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/14 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../lib64 -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/lib/../lib64 -L/lib -L/usr/lib /tmp/main-afb2d8.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/bin/../lib/gcc/x86_64-linux-gnu/14/crtendS.o /lib/x86_64-linux-gnu/crtn.o ld.lld: error: unable to find library -lstdc++ clang: error: linker command failed with exit code 1 (use -v to see invocation)

[Tachi107]

1. Stop installing the gcc package when using clang

gcc is pulled in by lcov:

$ apt depends lcov
lcov
  Depends: <python3:any>
    python3
  Depends: <perl:any>
    perl
  Depends: gcc   <-----------
  Depends: libcapture-tiny-perl
  Depends: libdatetime-perl
  Depends: libtimedate-perl
  Depends: libjson-perl
  Depends: libperlio-gzip-perl

This to me looks like a too stringent dependency by lcov, so I've filed a bug to the lcov package so that we can properly fix this. See https://bugs.debian.org/1085234

Also, next time please rebase your branch before marking it as ready for merging. Git commit histories like these are really unpleasing :/

[dgreatwood]

Yeah, but we do not only install the Meson package :)

[DG] Oh yes, you're right. As you know, there is one "apt -y install ..." line that installs all the packages, so in principle it could be any one (or more than one) of the desired packages that is pulling in "libstdc++-13-dev" as a dependency. I shouldn't assume it's meson.

gcc is pulled in by lcov:

[DG] OK, thanks for finding.

Your current workaround works but might break in the scenario where the default gcc depends on e.g. libstdc++-14-dev but libstdc++-15-dev becomes available, as that would get installed instead.

[DG] Yes, that is possible, though we have yet to see that case AFAIK (and we know that it currently breaks a lot - 30% of the time? - without the workaround).

This to me looks like a too stringent dependency by lcov, so I've filed a bug to the lcov package so that we can properly fix this.

[DG] Great.

Meanwhile, for an alternative to my current workaround, would you/could we consider not doing lcov, and not installing lcov, for debian:testing/clang case?

[Tachi107]

Meanwhile, for an alternative my current workaround, would you/could we consider not doing lcov, and not installing lcov, for debian:testing/clang case?

A workaround is a workaround, so as long as it works it's equally hacky to my eyes :)