Hello,
This comes from running namcap [0] on the output package. You can get similar info from ldd, but namcap saves a bit of time in this regard.
So I guess its one of the abstracted things rust links to without telling the user, as far as I can see every rust binary depends on gcc-libs for some reason, but I only checked a few packages.
Nothing to do with how rust does LTO, in fact I haven't looked at all into how rust does it. For your package specifically, it must be turned off due to this issue [1] reported by @orhun, one of the Arch Package Maintainers. Try turning on LTO, you'll see the compilation fail.
Are you sure this is not an isolated case? Admittedly I use a raw chroot, using pacstrap to install only base-devel and the dependencies listed in the PKGBUILD, and then simply chroot into it, create a build user and then clone the package into that home directory, and then build. As far as I am aware this manual method is fully conforms with dev tools, and therefore it should exhibit the same behaviour, but if I am wrong please let me know :) Oh and I know a lot of people who are reading this will tell me just to use dev tools, but I personally like making everything 100x harder for myself, so let me be me.
I use devtools [2] to build packages, which ensures clean chroots and also catches issues like this (it has some different defaults compared to just makepkg, including LTO on).
I have not explicitly enabled or disabled lto, so I do not know the default, however all the rust packages I have made have not had issues building in a clean chroot... Is lto by default enabled or disabled? I believe there was an RFC passed to enable it by default was there not? Thanks for the help, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev