On 6/14/23 13:10, Polarian wrote:
Are you sure this is not an isolated case?
In some cases Rust invokes the C compiler system to compile libraries into object files and for some reason the C compiler seems to remove parts of the public abi. I don't know why that is (I'm not that deep into the C lore), but it seems to be either a problem with `-flto=auto` or the way some C libraries define their public api (the ring crate in your case). I recommend to try building Rust projects with standard options first, and only add `options=(!lto)` if there are problems.
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 :)
The official way to build a package in Arch Linux is `pkgctl build`, that way you get the official Arch Linux build environment. If you invoke makepkg directly you aren't using devtools (makepkg is from the pacman package, which Arch Linux is building on top of with devtools), and you're likely using the wrong makepkg configuration, the official one is located at /usr/share/devtools/makepkg.conf.d/x86_64.conf You can see the difference here: % rg ^OPTIONS /usr/share/devtools/makepkg.conf.d/x86_64.conf 97:OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto) % rg ^OPTIONS /etc/makepkg.conf 95:OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
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.
If you expect support you should use the officially supported tools. 🤷 People might not care about your problems if you don't.