icc can't compile cryptopp,

icc can't compile cryptopp,

Deleted user's picture

Can anyone compile cryptopp with the icc?


http://www.eskimo.com/~weidai/cryptlib.html


I'm failing here:


icc -g -pipe -c elgamal.cpp
pubkey.h(209): warning #279: controlling expression is constant
assert(!"ProcessRecoverableMessage() not implemented");
^


misc.h(236): warning #186: pointless comparison of unsigned integer with zero
if (a < 0)
^
detected during instantiation of "std::string CryptoPP::IntToString(T, unsigned int) [with T=unsigned int]"


secblock.h(251): warning #186: pointless comparison of unsigned integer with zero
{assert(index >= 0 && (unsigned int)index < m_size); return m_ptr[index];}
^
detected during instantiation of "T &CryptoPP::SecBlock::operator[](I) [with T=byte={unsigned char}, A=CryptoPP::AllocatorWithCleanup, I=unsigned int]"


elgamal.h(81): error: identifier "MaxPlaintextLength" is undefined
unsigned int FixedMaxPlaintextLength() const {return MaxPlaintextLength(FixedCiphertextLength());}
^


compilation aborted for elgamal.cpp (code 2)
make: *** [elgamal.o] Error 2

16 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Micah Elliott (Intel)'s picture

What version of cryptopp are you trying to compile? I grabbed the latest 5.2.1 and had no problems compiling with new (9.1.044) and old (8.1.021) ICC compilers (IA-32).

It might be helpful for you to preprocess elgamal.cpp and attach it to this post. One of us can then try to repdoduce the error.

Deleted user's picture

joe@estara.com if you need it>

Micah Elliott (Intel)'s picture

Oops -- I thought this forum had a file upload mechanism!

I managed to paste your dump into a file. And it successfully compiles, again with old and new compilers. What compiler version are you using? It's IA-32, right? Does the failure occur with the preprocessed version?

Deleted user's picture

Yeah I looked for the upload for a while before giving up :). It's IA-32, fails with the preprocessed version too.


Intel C Compiler for 32-bit applications, Version 9.1 Build 20060927Z Package ID: l_cc_c_9.1.044


My CPU might be too slow, our 32-bit build box is somewhat dated:


processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 8
model name : Pentium III (Coppermine)
stepping : 6
cpu MHz : 861.107


It's also crazy slow using the ICC to compile my applications (8-10 minutes per file as opposed to4-5 seconds for gcc), soI can't use it for most of my applications, but I'm stillhoping to use it to compile apache/php/mysql and some crypto libraries we use.


Thanks for your help.


Joe

Micah Elliott (Intel)'s picture

I don't know why you would get the compile error. I'm using the same preprocessed file, options, and compiler as you, but no error!

Your "crazy slow" compile times should be unrelated to the error you're seeing, but they are quite disconcerting. Compile time should be on-par with GCC for most translation units. And your machine (PIII) should be fine -- unless your memory footprint gets out of hand and you start swapping to disk. Have you watched the memory usage of ICC (try top or memusage)? What type of license are you using -- does it involve the network? Is your network connectivity to your license server sane? Where does ICC reside -- on a local filesystem, or on NFS? Do other accesses to that filesystem appear slow?

Deleted user's picture

Fails on x64 too for me with:


icc -g -pipe -c 3way.cpp
/usr/include/gnu/stubs.h(7): catastrophic error: could not open source file "gnu/stubs-32.h"
# include


This is on Fedora Core 4.


Thanks,


Joe

Deleted user's picture

That is odd...


I'm using a trial version but everything else is pretty vanilla, no NFS, good network, no swapping, it's just the mcpcom process that runs for ~8 minutes per file. I'm too lazy to wait for 8 minutes here's what it looks like at 5 minutes:


top - 18:17:10 up 56 days, 1:40, 13 users, load average: 1.34, 1.10, 0.71
Tasks: 121 total, 2 running, 119 sleeping, 0 stopped, 0 zombie
Cpu(s): 50.4% us, 1.2% sy, 0.0% ni, 48.4% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 2070580k total, 1682844k used, 387736k free, 341660k buffers
Swap: 2031608k total, 68k used, 2031540k free, 604740k cached


PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
31100 builder 25 0 72892 51m 4076 R 99.1 2.5 5:15.70 mcpcom


Perhaps it's because I'm building for multiple targets -axNP, or I shouldn't use -O3? e.g.:


icc -fPIC -D_REENTRANT -D_GILFDSET-axNP -O3 -Wall -c -o linux-i386/moduleimp.o moduleimp.cpp


Thanks,


Joe

Deleted user's picture

I got the 64-bit compile going by installing glibc-devel-2.3.6-3 [ i386 version inaddition to the 64bit version], it fails in exactly the same place compiling cryptopp as under the 32 bit version.


I also tried compiling just the two failing files with: gcc -g -pipe -c elgamal.cpp; gcc -g -pipe -c validat2.cpp


But then I can't link.


I also tried every different possible combo of options to icc, and they make no difference to the mcpcom "7 minutes to compile each file" issue. The issue exists under 64bit too, it's just 2 minutes instead.


I'm using ccache so this is borderline acceptable to me now on that machine, if I can use it to build for all architectures.


Thanks for your support,


Joe

Micah Elliott (Intel)'s picture

> I also tried compiling just the two failing files with: gcc -g -pipe -c elgamal.cpp; gcc -g -pipe -c validat2.cpp

> But then I can't link.


Mixing/matching GNU-compiled objects with ICC-compiled objects should not be a problem. Make sure you're using icpc for the link.


> still slow compile


Which of the files is giving the horrific compile time? Most of them? I might be able to find a PIII to try and reproduce on. Is this even at -O0?

Deleted user's picture

> Mixing/matching GNU-compiled objects with ICC-compiled objects should not be a problem. Make sure you're using icpc for the link.


I still don't understand how it can fail for me under PIIIand P4, 32bit and 64bit both in the same placebut work for you. Very odd. icpc versus icc to link doesn't change anything that I can see.


I think the error is an i386/x86_64 error, the key one that I picked out of the 4800 errors is:


ld: warning: i386:x86-64 architecture of input file `validat2.o' is incompatible with i386 output.



But I can't force i386: g++ --pipe -c -march=i386 elgamal.cpp
elgamal.cpp:1: error: CPU you selected does not support x86-64 instruction set


And using -m64 versus -m32 doesn't help either. I also tried building -axN which didn't change anything


The horrific compile time is for our internalcode unfortuantely -- it's on both P4 and PIII that it occurs, I'd just let that pass (and use ccache to mitigate the slowness), if I could get crypto521 to compile into something I can use I'd probably be okay.


Joe

dries.decock@excentis.com's picture

I have the same problem here. When compiling crypto++ using icc 9.1.045, it stops on the same code.

weidai's picture

Hi, I'm the author/maintainer of Crypto++. I can't install ICC due to the installer not recognizing my serial number and license file. However I think there is a good chance this compileproblem can be fixed by adding"this->" in front of "MaxPlaintextLength" on the line that is causing the compiler error.


If you guys have future problems with the Crypto++ library, you can post them to the Crypto++ mailing list which I monitor much more frequently.

dries.decock@excentis.com's picture

This fixes the problem indead. Thank you !

weidai's picture

I'd like to note, for those who might arrive on this page by search engine, that the latest release of Crypto++ (version 5.5) should compile with Intel C++ Compiler 9.1 out of the box. It's available from http://www.cryptopp.com.

llazzaro's picture

I had the same error. I fix it installing libc i386

hope ot helps

icc version : 11.0

Login to leave a comment.