Hello to all. I am running the latest Linux Mint. Today I was offered to upgrade dkms, and accepted (which I always do). This in turn installs the new packages
cpp-12
gcc-12
libasan8
libgcc-12-dev
libtsan2
After this the chapel compiler breaks with the message:
/usr/bin/ld: cannot find -lstdc++: No such file or directory
because apparently libstdc++.a and libstdc++.so have been wiped out by the upgrade. My quick and dirty fix is
$ cd /usr/lib/x86_64-linux-gnu/
$ sudo ln -s libstdc++.so.6.0.30 libstdc++.so
Cheers Nelson
1 Like
Hi Nelson —
To clarify: Are you looking for a more principled fix, or just sharing this knowledge in case it helps others? 
In either case, after you upgraded, did you rebuild Chapel? And did you rebuild it by just using make or something more extreme like a new install of the tarball or a make clobber before make?
Lastly, is this with Chapel 1.29.0?
Thanks,
-Brad
Hi Brad: I am just sharing because it may be useful to people in the same situation. I did not rebuild Chapel. It appears that somewhere inside the compiler it will look for libstdc++.a or libstdc++.so (in my case .so sufficed) and will proceed happily if it finds one. Therefore, after I created a link with the missing name, compilation resumed smoothly (so far: have to test more ...) and yes it is 1.29.0
Cheers
Nelson
1 Like
OK, thanks, Nelson! I believe that as we've made greater use of LLVM and Cmake, our build process has been doing more querying and caching of information (like paths to libraries) than it traditionally had. And when things go off the rails, this complaint about not finding libstdc++ seems to be the most immediate and common symptom.
If you hadn't asserted that there is no libstdc++ anymore, I'd definitely be curious whether a fresh build with your new packages installed (and no symbolic links) would hit this same error, a different error, or simply work. Specifically, my guess would have been that something had cached a path to where libstdc++ used to live, then the update removed that library, so it's not being found anymore.
However, I wouldn't imagine that the build process would recognize libstdc++.so.6.0.30 as a valid libstdc++, so would be surprised if it automatically started using it (though I could be wrong about that). And if there were no other libstdc++ on your system, then I'm not sure what would happen, though I'd imagine things would break during the build itself rather than after the build / when trying to use chpl.
No need to look into any of this for my sake, though, especially if things are already working well for you. Just wanted to capture some thoughts and notes for others who might land on this discussion in the future.
-Brad
Hi again Brad: my "quick fix" actually took a couple of hours. My first reaction was to download the tarball again, "source util/setchplenv.bash", and "make" to see if things got fixed, but no: I got exactly the same error. To the best of my knowledge: there was only one libstdc++.so in the root directory; after the dkms there was none, and that was the problem. But curiously, as far as I could tell, the "make" succeeded...
Cheers again
Nelson
Ah, OK, thanks for clarifying. When you said:
I misunderstood that to mean that you had not done the download + build from scratch. But now I believe you mean that once you figured out the ln -s approach above, your previous installation worked without needing to be rebuilt?
-Brad