Closed prototype99 closed 6 years ago
Hi @prototype99 Reviewing the log file I noticed the following in the end:
commands.o:(.data.rel.ro._ZTVN8CryptoPP16BlockCipherFinalILNS_9CipherDirE1ENS_8Rijndael3DecEEE[_ZTVN8CryptoPP16BlockCipherFinalILNS_9CipherDirE1ENS_8Rijndael3DecEEE]+0xa8): undefined reference to `CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const'
commands.o:(.data.rel.ro._ZTVN8CryptoPP16BlockCipherFinalILNS_9CipherDirE1ENS_8Rijndael3DecEEE[_ZTVN8CryptoPP16BlockCipherFinalILNS_9CipherDirE1ENS_8Rijndael3DecEEE]+0x120): undefined reference to `non-virtual thunk to CryptoPP::Rijndael::Dec::AdvancedProcessBlocks(unsigned char const*, unsigned char const*, unsigned char*, unsigned long, unsigned int) const'
I found an issue not directly related that mentioned the following:
Rijndael::Dec::AdvancedProcessBlocks is available when CRYPTOPP_BOOL_AESNI_INTRINSICS_AVAILABLE (AES-NI) is defined. Also see rijndael.h. I'm guessing (and its purely a guess), Crypto++ library is being built without AES-NI support. Then, the application (like Kovri), is being built with AES-NI support. They library and the application must both be built with the same flags. In some cases, the same compiler and same C++ runtime must be used, too. For Clang, try adding -march=native or -maes to your CXXFLAGS. You might also be hitting this bug caused by the GCC 5 ABI change: http://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/ . This is a case where you should use the same compiler and runtime. I kinda expected this to be a bigger problem than shows up in the field because distros like Debian compile with SSE2 enabled but not much more. Debian's Crypto++ library will lack Rijndael::Dec::AdvancedProcessBlocks, while users with a modern processor will have Rijndael::Dec::AdvancedProcessBlocks enabled because AES-NI is available.
I think that this is related to cryptopp use flag that should install dev-libs/crypto++. Since this is already a dependency for megasync and use flag cryptopp is active by default, I would like to know what dev-libs/crypto++ version you have installed as also cmake and gcc?
I compiled it with dev-libs/crypto++-5.6.5-r1, cmake-3.11.1 and gcc-6.4.0-r1.
Also try emerge with MAKEOPTS="-j1".
passing the -j1 argument does not appear to help, the only version difference is cmake-3.9.6. would updating it cause any issues? (what improvements are there if you can recall?) also, do you think i should ideally have the qt5 flag enabled? system-jsoncpp piqued my interest so i enabled that and tested for any clear difference, however it was still the same. my kernel does not have AES-NI enabled (isn't that limited to intel? mine is an amd ryzen pc so i put =n for the relevant kernel option).
Hi @prototype99
AES-NI instruction set from intel actually should be the same as AES from AMD. I think that the problem is not related with the instruction set.
I received an hint that there is a missing dependency in the ebuild:
I'll add this dependency to the 2 most recent releases 3.6.0-r1 and megasync-3.6.5. I'll create a new release for both.
alright i'll let you know how it goes and close it if it's fixed
yep all good thank you! even with the large number of gcc options i use, it now compiled alright. i would check version 3.6.5 for you as well, but emerge seems to have a problem with telling it to install any package ending in -rX (saying there's no ebuild) if you have an idea how to resolve that, i'll happily test that too
Hi @prototype99
You can install a package with -rX like any other. For instance:
emerge -av =net-misc/megasync-3.6.5-r1
this should install the latest version available.
I'm using the ebuild versioning using the preconized syntax for revisions:
https://devmanual.gentoo.org/general-concepts/ebuild-revisions/index.html
https://devmanual.gentoo.org/ebuild-writing/file-format/index.html
About package install you can review more details on the following page:
https://wiki.gentoo.org/wiki/Version_specifier
If you can't find the latest version I mentioned before try a layman sync again for the overlay:
layman -s ssnb
oh perhaps the layman sync was what i needed, anyway that version also works so i'd say it should be all good now!
hello, i recently tried updating megasync and found that the package will not compile. the error is reproducible as i was able to consistently reach the same result in all 5 attempts. attached is a relevant log produced with the &tee command, if anything else is needed to help resolve the issue please feel free to ask. log.TXT