When you run an update of cryfs it will always fail at steps 106/188 and 107/188, no matter if you use O2/O3 and/or -j1 or another value Reproducible: Always Steps to Reproduce: 1. sudo emerge -av1 sys-fs/cryfs Actual Results: Fails Expected Results: Upgrade
Created attachment 703257 [details] emerge log
(In reply to Marco Scardovi from comment #1) > Created attachment 703257 [details] > emerge --info Sorry, emerge log
Created attachment 703260 [details] emerge --info '=sys-fs/cryfs-0.10.2::gentoo'
>../src/blobstore/implementations/onblocks/parallelaccessdatatreestore/../datatreestor>e/../datanodestore/DataNodeView.h:86:33: error: use of deleted function >‘cpputils::Data::Data(const cpputils::Data&)’ > 86 | cpputils::Data serialized = _serialize(layout, formatVersion, depth, >size, std::move(data));
Side note: changing optimization's flags is useless as it is forcing O3 by default
Adding USE="custom-optimization" will force this package to use what you've set in make.conf, but that doesn't fix this issue. Compiling sys-fs/cryfs with clang seems to resolve this specific issue, though I can't say that won't introduce other issues down the line.
(In reply to Drew W from comment #6) > Adding USE="custom-optimization" will force this package to use what you've > set in make.conf, but that doesn't fix this issue. Compiling sys-fs/cryfs > with clang seems to resolve this specific issue, though I can't say that > won't introduce other issues down the line. I can understand that thing if a program is known to breaks setting an higher O flag but forcing an higher flag than the one suggested by gcc shouldn't be normal, in my mind
(In reply to Drew W from comment #6) > Adding USE="custom-optimization" will force this package to use what you've > set in make.conf, but that doesn't fix this issue. Compiling sys-fs/cryfs > with clang seems to resolve this specific issue, though I can't say that > won't introduce other issues down the line. I can confirm compiling this package with clang resolved the issue for me too.
Looks like a simple name clash to me: ... error: macro "_serialize" passed 5 arguments, but takes just 0 ... /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include/serializeintrin.h:37: note: macro "_serialize" defined here 37 | #define _serialize() __builtin_ia32_serialize () ... So GCC-11 has defined macro _serialize() now. Just adding namespace to _serialize inside DataNodeView.h should solve this, e.g. DataNodeView::_serialize().
Created attachment 704547 [details, diff] patch Adding namespace is not enough, because _serialize is a macro in gcc. Attached patch fixes cryfs, but I guess it would be better to rename _serialize in cryfs.
Had the same issue, was failing at 113/188 here though. Put the patch file in /etc/portage/patches/sys-fs/cryfs-0.10.2/cryfs.patch Builds fine now. Thanks
(In reply to Stephan Hartmann from comment #10) > Created attachment 704547 [details, diff] [details, diff] > patch > > Adding namespace is not enough, because _serialize is a macro in gcc. > Attached patch fixes cryfs, but I guess it would be better to rename > _serialize in cryfs. IMO it is generally a bad idea to begin the name of an identifier with an underscore, unless you are writing system headers. I stick the underscore at the end, instead. (I don’t know C++, but the C standard would reserve ‘_serialize’ for use as a file scope identifier. So not so bad. But I’d still call it ‘serialize_’.)
(In reply to Barry Schwartz from comment #12) > (In reply to Stephan Hartmann from comment #10) > > Created attachment 704547 [details, diff] [details, diff] [details, diff] > > patch > > > > Adding namespace is not enough, because _serialize is a macro in gcc. > > Attached patch fixes cryfs, but I guess it would be better to rename > > _serialize in cryfs. > > IMO it is generally a bad idea to begin the name of an identifier with an > underscore, unless you are writing system headers. I stick the underscore at > the end, instead. > > (I don’t know C++, but the C standard would reserve ‘_serialize’ for use as > a file scope identifier. So not so bad. But I’d still call it ‘serialize_’.) I forgot to say that the patch works for me, too.
*** Bug 788403 has been marked as a duplicate of this bug. ***
Same here. For your reference: https://github.com/cryfs/cryfs/issues/389
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=3d938ca65dc367476475ef148fd20cb2cf1472f7 commit 3d938ca65dc367476475ef148fd20cb2cf1472f7 Author: Sam James <sam@gentoo.org> AuthorDate: 2021-05-10 10:46:20 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2021-05-10 10:46:48 +0000 sys-fs/cryfs: add GCC 11 patch (And fix the paths from PR which I hadn't staged...) Closes: https://bugs.gentoo.org/786459 Signed-off-by: Sam James <sam@gentoo.org> sys-fs/cryfs/cryfs-0.10.3.ebuild | 7 +- sys-fs/cryfs/files/cryfs-0.10.3-gcc11.patch | 271 ++++++++++++++++++++++++++++ 2 files changed, 276 insertions(+), 2 deletions(-)