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.
