Arch Linux User Repository

@alerque I see, although I was not aware whenever CFLAGS has worked with Rust compiler or if it was an issue related to LTO at the beginning. I just followed the Rust compiler recommendations around fixing this:

  = note: some `extern` functions couldn't be found; some native libraries may need to be installed or have their path specified
  = note: use the `-l` flag to specify native libraries to link
  = note: use the `cargo:rustc-link-lib` directive to specify the native libraries to link with Cargo (see https://doc.rust-lang.org/cargo/reference/build-scripts.html#cargorustc-link-libkindname)

I'm also not sure whenever this certain modification to env vars would help at all, especially when it seems that only thing that was needed to fix it was to add mimalloc to the linker command-line so there's no missing references to it. But I have very little experience with the LTO issues when I build packages in general.

As of disabling LTO, wouldn't it be better to patch or modify the sources instead to make building with LTO possible than just disable LTO to basically avoid fixing the problem? This was the reason why I stayed at build.rs solution rather than to set options=(!lto) when I figured out the errors I've encountered with Cargo were actually related to LTO in some way.

I should also say, build.rs only messes with the build env and allows to manipulate with stuff like the linker flags (so this isn't exactly messing with the upstream sources; I don't intent patching sources nor modifying it in any other way unless patches are required to build it on Arch with the latest build env and no fixes has reached the stable builds). I guess if CFLAGS words, LDFLAGS could work as well and with that adding a missing reference to the library in command-line could help as well. But it matters not now, as with the update to the next version I've removed build.rs so when building, Rust will use now the upstream ones.

I've also didn't introduced this as patch, because there was nothing to patch back then. The build.rs just didn't exist before.

Also, FYI, here's the report I've made to the upstream back then: https://github.com/LyonSyonII/hunt-rs/issues/8. As said before, once it was resolved and the solution picked by the upstream was introduced, I've removed my own code to follow the upstream.

Most LTO build issues can be fixed by adding this to the build function: CFLAGS+=' -ffat-lto-objects'. The few that can't can be disabled entirely with options=(!lto). Of course also reporting it upstream is appropriate, but those are the correct way to fix the packaging not messing with the upstream sources.

@alerque this was a workaround for people with lto flags enabled in their build env. I'm actually the one who reported hunt doesn't build with lto (at least for me) and proposed build.rs as a workaround.

It'll be okay to remove it for the future releases (once I'll update hunt to the next version and test whenever it works on my PC), but when building older hunt this is currently a must-have unless you don't intent to build hunt with lto enabled.

Please do not change the upstream build.rs file! If something is wrong report it upstream and add a patch file so we can see what is being changed. The current arrangement makes it very hard to even see what you are doing and why (and I think it is moot anyway now).

Looks like the linker errors only happens with LTO enabled in makepkg (i.e. with options array containing lto either within the makepkg.conf or PKGBUILD). This means the error could not be reproducible before by many users and was clearly a thing on my side. That being said, I doubt the said build.rs script to be harmless to the users with the LTO disabled and supporting LTO envs during build process is for sure a good thing to have.

I should also say, I've already resolved the problems @wakamue has mentioned. Given I still have some plans to do some rather cosmetic changes in the script itself, following Rust package guideliness to hopefully keep the overall PKGBUILD more consistent with the other packages, you might also expect for some changes to happen. I won't be bumping pkgrel for now, since I doubt I'll modify anything that much that it will affect the resulting package.

I forgot to add build.rs to sources array. I'll fix that as soon as I'll be near my PC (in the next week), I suppose it isn't hard to add it on your own there. The file itself is a workaround for the build errors caused with lack of the library in the linter command line when compiling with Rust. I guess it would be desirable for an upstream to define it by itself, I suppose I might consider reporting this at upstream and maybe making a PR on GitHub.

Found hunt-2.1.0.tar.gz ==> ERROR: Integrity checks (sha512) differ in size from the source array.

After skipping the integrity check: Starting prepare()... install: cannot stat '../build.rs': No such file or directory