samuelbernardo / ssnb-overlay

My public gentoo overlay
7 stars 2 forks source link

net-misc/megasync-3.6.0-r1 emake failed #9

Closed prototype99 closed 6 years ago

prototype99 commented 6 years ago

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

samuelbernardo commented 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".

prototype99 commented 6 years ago

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).

samuelbernardo commented 6 years ago

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.

AMD Ryzen

Intel i9

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.

prototype99 commented 6 years ago

alright i'll let you know how it goes and close it if it's fixed

prototype99 commented 6 years ago

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

samuelbernardo commented 6 years ago

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

prototype99 commented 6 years ago

oh perhaps the layman sync was what i needed, anyway that version also works so i'd say it should be all good now!