"/usr/bin/ld: cannot find -lstdc++: No such file or directory" on running flutter linux app – Ubuntu

I ran into a similar problem after a system upgrade. After a while, I realized that it was because nvidia-driver-520-open installed gcc-12. I use clang-15 that I installed with the script installClang15.sh. clang-15 depends and hence installs libstdc++-11-dev and gcc-11. The problem is that once gcc-12 was installed, clang++ picked it up automatically instead of gcc-11. This can be confirmed with clang++ --verbose which outputs something like

Ubuntu clang version 15.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/local/bin
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/11
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/12
Candidate multilib: .;@m64
Selected multilib: .;@m64

Solution 1: Install libstdc++-12-dev

I thought about this solution thanks to this GitHub comment. This is the easiest solution, but it has a few drawbacks. On Ubuntu, you can install the package with

sudo apt install libstdc++-12-dev

The drawbacks that I faced are:

• I’d then be using a newer version of gcc (version 12). This might required (actually this did require) me to update my code. This is very problematic within the context of this question, where one doesn’t necessarily control the code.
• What if in 6 months, nvidia-driver-520-open requires gcc-13? I would have to figure out again why I’m having this error, and then install libstdc++-13-dev, which might potentially require some code updates again.

Solution 2: Fix the gcc installation that clang++ uses

I did not find any clean and easy way to do that, but there are ways. clang-16, not yet released as of November 28th 2022 but available when building clang, has a new option --gcc-install-dir described here. This fixes compilation:

$HOME/src/llvm-project/staging/bin/clang++ --gcc-install-dir=/usr/lib/gcc/x86_64-linux-gnu/11 a.cpp

where a.cpp is a trivial C++ "Hello World!" program

#include <iostream>
int main() { std::cout << "Hello World!" << std::endl; }

Older versions of clang have the option --gcc-toolchain, which is not quite as useful for reasons described on llvm’s discourse. However, you can still be ingenious and do what this Stack Overflow answer suggest. The TL;DR is

sudo mkdir --parents /opt/gcc-root/lib/gcc/x86_64-linux-gnu
sudo ln --symbolic /usr/lib/gcc/x86_64-linux-gnu/11 /opt/gcc-root/lib/gcc/x86_64-linux-gnu/11
sudo ln --symbolic /usr/include /opt/gcc-root/

The ln --symbolic /usr/include /opt/gcc-root/ is important, otherwise I encountered problems with incremental build. Then, you should be able to compile with

clang++ --gcc-toolchain=/opt/gcc-root a.cpp

This leaves one question open: "How do I integrate this compiler option system wide?" I didn’t find any satisfying answers here.

• You could use export CCC_OVERRIDE_OPTIONS=^--gcc-toolchain=/opt/gcc-root as described here and documented on GitHub. This might be the best solution within the context of this question.
• You could create a shell script named clang++ that contains

  #!/usr/bin/env bash
  /usr/local/bin/clang++ --gcc-toolchain=/opt/gcc-root "$@"
  

  and then use export CXX=<PATH_TO_SCRIPT>/clang++. This work well enough in practice: it’s been my quick and dirty fix. However, I’m worried that other tools in the toolchain (like clang-tidy or clangd) might have problems if they’re not passed the option --gcc-toolchain. Depending on how you are setup, they might not see the option since it would not be in the file compile_commands.json created with the CMAKE_EXPORT_COMPILE_COMMANDS CMake variable.

• You could use clang’s configuration files. The TL;DR is that you symbolically link clang++ as, for instance, fixed-gcc-root-clang++, and then you create a file fixed-gcc-root-clang++.cfg in the proper place (for clang-15, it is /usr/lib/llvm-15/bin) that contains the option --gcc-toolchain=/opt/gcc-root. Finally, you use export CXX=fixed-gcc-root-clang++. A problem is that if somebody or something (for instance an IDE) uses clang++ directly, your configuration file won’t be read. You’ll also have problems if a new symbolic link to fixed-gcc-root-clang++ is created, for instance c++ -> fixed-gcc-root-clang++, since in this case, the configuration file would not be read.
• The best solution I found requires to control the build system, so it doesn’t apply within the context of this question. The solution is to modify your build system toolchain. I find this unsatisfying since a packaging problem (remember, this is all because nvidia-driver-520-open installed a new transitive dependency) finds its solution in the C++ build system. Hence, the separation of concerns principle is not respected.