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
NOTE: kpcyrd originally sent this offlist to me, and has just sent it here, so below as my response to them. Hello, before I reply to your email, I would like to ask why you offlisted me instead of keeping this onlist? parts of the public abi. I believe this is because a lot of rust libraries are "safe" wrappers on top of C libraries. I believe the rust handbook has something on this, you are meant to set a C compiler along with the linker of choice when configuring rust because of the heavy use of C still. I did not realise however this was the reason for the linking issues, not that I have ran into linking issues yet with packaging rust, because I have not packaged any large rust application.
I recommend to try building Rust projects with standard options first, and only add `options=(!lto)` if there are problems.
The official way to build a package in Arch Linux is `pkgctl build`,
Way ahead of you here, I already do this and thus I was a little confused when I was told to add this option, hence why I asked for clarification. 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)
The only useful flag here for when you are testing in clean chroots is the debug flag being enabled. The LTO flag being enabled by default was as I expected, due to the RFC which was passed a little while ago which suggested LTO should be used by default. I would like to highlight that the built packages are only used for my unofficial repository, and as I am not a trusted user/package maintainer therefore this is not the biggest deal, although like I said above the debug flag is good for testing PKGBUILDs which I will keep in mind. Also there seems to be more differences: ~ on ☁ ❯ diff /etc/makepkg.conf /usr/share/devtools/makepkg.conf.d/x86_64.conf 1a2,3
# shellcheck disable=2034
47c49 < #RUSTFLAGS="-C opt-level=2" ---
RUSTFLAGS="" 49c51 < MAKEFLAGS="-j13"
#MAKEFLAGS="-j2" 53c55 < #DEBUG_RUSTFLAGS="-C debuginfo=2"
DEBUG_RUSTFLAGS="-C debuginfo=2" 95c97 < OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge !debug !lto)
OPTIONS=(strip docs !libtool !staticlibs emptydirs zipman purge debug lto) 140c142 < COMPRESSZST=(zstd -c -z -q -)
COMPRESSZST=(zstd -c -T0 --ultra -20 -) 159c161,162 < PACMAN_AUTH=(doas)
#PACMAN_AUTH=() # vim: set ft=sh ts=2 sw=2 et:
appears the devtools compress the final package more as well. Apart from my changes to MAKEFLAGS and PACMAN_AUTH my makepkg.conf is stick on my laptop. Thanks for pointing out these differences, I will update the makepkg configuration I use on my build server for my unofficial repository to better reflect this.
If you expect support you should use the officially supported tools. 🤷 People might not care about your problems if you don't.
Two points I would like to make: 1. I believe the purpose of the above comment was to discourage me from doing stuff manually and just using the same tools as everyone else (well most people). I will still rather do it myself, and use my own configurations which is important when it comes to MAKEFLAGS as -j needs to be assigned to more than 2 threads considering my build server has that. 2. It is not fair to say that because I do not use the same tools that I should not be given support for completely unrelated problems. The problem with this package is not the build process failing (also I would like to point out that users will build this from the AUR therefore if the default makepkg.conf doesn't work then its a little useless sticking it on the AUR don't you think?). The problem was an install time issue, most likely due to poorly written tmpfiles, that was what I was asking help with, as the subject suggests. I would also like to highlight that the only reason the build was brought up was because éclairevoyant brought up the fact that lto might break, and the fact gcc-libs is linked against. I am fully aware that not building packages conventionally means its my problem if it goes wrong, but having everything given to me in a tool is against my way of doing things, cannot learn if you don't cut out the abstraction, and therefore I would rather use the raw tools instead of devtools which does a massive amount of automation. However, I would like to thank you again for pointing out the different maakepkg configurations, and for explaining the need to disable LTO if the rust package breaks while using it. Have a good night, -- Polarian GPG signature: 0770E5312238C760 Website: https://polarian.dev JID/XMPP: polarian@polarian.dev