> The other system where it does not work: >>> >>> $ cat /etc/issue >>> Ubuntu Xenial Xerus (development branch) \n \l >>> >>> $ nm /usr/lib/libcryptopp.a | c++filt | grep DEFAULT_CHANNEL >>> U CryptoPP::DEFAULT_CHANNEL[abi:cxx11] >>> >>> and there we go: >>> http://allanmcrae.com/2015/06/the-case-of-gcc-5-1-and-the-two-c-abis/ >>> <http://www.google.com/url?q=http%3A%2F%2Fallanmcrae.com%2F2015%2F06%2Fthe-case-of-gcc-5-1-and-the-two-c-abis%2F&sa=D&sntz=1&usg=AFQjCNGJB-Ew66mPIEbBv3pMfr1Gmg4hDg> >>> >> >> Oh, that was a good find. Sorry about providing the standard sermon. >> >> So I'm clear (and can update the docs): Can the issue be summarized as: >> >> * GCC 5.1 and above >> * 5.1 uses a "abi:cxx11" tag in its name mangling >> * Clang does not use the "abi:cxx11" tag >> >> Open question: platforms affected? Debian {Testing|Sid}?, Arch? >> Open question: does -std=XXX affect it? >> >> I'm thinking the advice of "use the same compiler, options and defines >> for both the library and applications" still holds. Can you confirm its OK? >> Or can you suggest a change to the text to account for this scenario? >> >> Jeff >> > > It's not matter of compiler, it depends if when the libstd++ was compile > the _GLIBCXX_USE_CXX11_ABI was defined or not. See: > https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_dual_abi.html >
OK, thanks. We have a test/QA script that repeatedly builds the library under various conditions at http://github.com/weidai11/cryptopp/blob/master/cryptest.sh. I run it all the time while testing changes. So I guess my question is... Is there an actionable item for us to perform regarding this issue? If so, what needs to be done and what are the options to achieve the objective? About which distribution AFAIK: > Ubuntu 16.04/15.10 uses GCC 5.x and they are using the abi_tag so > basically until clang doesn't understand the tags it will not work. > OK, thanks. I have a test machine with Ubuntu 16, but it did not uncover the issue. The test script tests building an installing the library. It does not test a distro's copy of the library. Is our only choice to tell users to build the library and program with same compiler, options and defines? Or is there something else we can consider? Jeff -- -- You received this message because you are subscribed to the "Crypto++ Users" Google Group. To unsubscribe, send an email to [email protected]. More information about Crypto++ and this group is available at http://www.cryptopp.com. --- You received this message because you are subscribed to the Google Groups "Crypto++ Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
