Search Criteria
Package Details: hunt 3.0.0-1
Package Actions
Git Clone URL: | https://aur.archlinux.org/hunt.git (read-only, click to copy) |
---|---|
Package Base: | hunt |
Description: | Highly-opinionated simplified Find command made with Rust |
Upstream URL: | https://github.com/LyonSyonII/hunt-rs |
Keywords: | find locate rust search |
Licenses: | MIT |
Submitter: | omasanori |
Maintainer: | SpacingBat3 |
Last Packager: | SpacingBat3 |
Votes: | 2 |
Popularity: | 0.002570 |
First Submitted: | 2022-07-15 00:39 (UTC) |
Last Updated: | 2024-11-30 00:10 (UTC) |
Dependencies (1)
- cargo (rustup-gitAUR, rust-nightly-binAUR, rust-gitAUR, rust-beta-binAUR, rustup-stubAUR, rust, rustup) (make)
Latest Comments
SpacingBat3 commented on 2024-03-24 20:00 (UTC)
@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: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 setoptions=(!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 ifCFLAGS
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.
alerque commented on 2024-03-19 12:16 (UTC)
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 withoptions=(!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.SpacingBat3 commented on 2024-03-09 13:03 (UTC) (edited on 2024-03-09 16:01 (UTC) by SpacingBat3)
@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 proposedbuild.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 olderhunt
this is currently a must-have unless you don't intent to buildhunt
with lto enabled.alerque commented on 2024-03-07 10:28 (UTC)
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).SpacingBat3 commented on 2024-03-02 17:56 (UTC)
Looks like the linker errors only happens with LTO enabled in
makepkg
(i.e. withoptions
array containinglto
either within themakepkg.conf
orPKGBUILD
). 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 saidbuild.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 bumpingpkgrel
for now, since I doubt I'll modify anything that much that it will affect the resulting package.SpacingBat3 commented on 2024-02-25 15:02 (UTC)
I forgot to add
build.rs
tosources
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.wakamue commented on 2024-02-25 08:51 (UTC)
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