Search Criteria
Package Details: securefs 0.13.1-1
Git Clone URL: | https://aur.archlinux.org/securefs.git (read-only, click to copy) |
---|---|
Package Base: | securefs |
Description: | A better transparent encryption filesystem |
Upstream URL: | https://github.com/netheril96/securefs |
Licenses: | MIT |
Submitter: | mrxx |
Maintainer: | mrxx |
Last Packager: | mrxx |
Votes: | 8 |
Popularity: | 0.000012 |
First Submitted: | 2016-03-26 21:34 (UTC) |
Last Updated: | 2022-11-18 17:10 (UTC) |
Dependencies (5)
Required by (3)
- sirikali (optional)
- sirikali-bin (optional)
- sirikali-git (optional)
Latest Comments
1 2 3 4 Next › Last »
ccorn commented on 2024-01-21 01:30 (UTC)
For an update, apply the following changes:
This depends on the AUR package abseil-cpp11 with the runpath patch.
mrxx commented on 2023-10-08 19:01 (UTC) (edited on 2023-10-08 19:03 (UTC) by mrxx)
v0.14.3 is out, but I get the following error with crypto++ and cryptopp either.
emmieaur commented on 2022-12-01 05:54 (UTC)
Yeah, I think it will need a more generic regular expression. Just tried to build today and I got
error: unknown target CPU 'native -O2 -pipe -fstack-protector-strong'
. The * didn't work for me since mine lacked the-fno-plt
.mrxx commented on 2022-11-18 17:14 (UTC)
Thank you, wildcard added as suggested.
MCOfficer commented on 2022-11-09 23:43 (UTC)
Here's another edge case for the $CXX regex:
unknown target CPU 'x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong -fno-plt'
.Can confirm that just adding another wildcard works (
...-pipe.*-fno-plt"
), but perhaps an even more generic regex is needed at this point.mrxx commented on 2022-06-15 23:42 (UTC)
Thank you for the suggestion, I've included the wildcard extension to the fix.
teras commented on 2022-06-11 09:47 (UTC) (edited on 2022-06-11 09:48 (UTC) by teras)
I found the problem. The fix provided by @mrxxm actually doesn't work on my system. Instead of replacing
"-march=x86-64 -mtune=generic -O2 -pipe -fno-plt"
on my system the string is"-march=x86-64 -mtune=generic -O2 -pipe -fno-plt -fexceptions -Wp,-D_FORTIFY_SOURCE=2 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -Wp,-D_GLIBCXX_ASSERTIONS"
. Since this solution is already too hairy for me, I dared to replace with this:"-march=x86-64 -mtune=generic -O2 -pipe -fno-plt.*"
(notice the wildcard) and of course it worked.I am not sure if this should be the correct behavior, or understand why the CXX flag was messed up (and maybe report upstream to more Arch developers if they have an idea about it).
connesc commented on 2022-06-09 13:51 (UTC) (edited on 2022-06-09 13:51 (UTC) by connesc)
@teras: I observe the same behavior. I think the difference is that
makepkg
sets theCXXFLAGS
environment variable. This is incorrectly handled somewhere and the variable gets duplicated with extraneous quotes.teras commented on 2022-05-22 15:46 (UTC) (edited on 2022-05-22 16:02 (UTC) by teras)
I let some time to pass just in case it's another system-related problem, but unfortunately I have exactly the same problem. Interestingly, when I tried to compile by hand using the following commands, I didn't have any issues:
EDIT Some more comments: If I let
makepkg
to do the work, the package breaks indeed. If, on the same folder that PKGBUILD is, I do exactly the same commands manually, the package is compiled!Should it be a problem of
makepkg
? Does it make any sense?mrxx commented on 2022-05-16 20:28 (UTC)
@teras, I had noticed this upstream regression and included a fix.
I've extended it now to all .make files. Please clear your build directory and try again.
1 2 3 4 Next › Last »