On Friday, October 14, 2016 at 5:37:35 AM UTC-4, Andrew Marlow wrote:
>
> Hello everyone,
>
> I am trying out cryptopp-565 to see if it resolves the problems I have 
> been seeing on Solaris 11 using the Sun compiler version 12.4. To this end 
> I have written a standalone program that shows the problem. When I got 
> version 565 I thought I would try building my test program with g++ first. 
> The cryptopp lib itself builds fine and the tests all run and pass. The 
> benchworks also seem ok. And it all works on RHEL 6.8 and my test program 
> works ok there also. But on solaris 11 where I have g++ version 4.8.2 I get 
> a compilation error:
>
> g++ -DNDEBUG -g2 -O2 -fPIC -pipe -c apmtest.cpp
> In file included from apmtest.cpp:6:0:
> config.h:582:34: error: operator '>=' has no left operand
>  #if ((__ILP32__ >= 1) || (_ILP32 >= 1)) && defined(__x86_64__)
>
> Since this is fine on RHEL I presume the problem is related to the solaris 
> environment. It looks like there the _IP32 macro is not defined. I notice 
> that the Sun/Oracle documentation at 
> https://docs.oracle.com/cd/E19683-01/806-6543/chapter4-2/index.html says 
> that this macro is used to say that the sizes of int, long, and pointer 
> are all 32 bits. There is something strange about that macro though. Here 
> is another little program that fails to compile:-
>
> #include <iostream>
>
> int main()
> {
> #if defined(_ILP32)
>     std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";
> #else
>     std::cout << "_ILP32 macro is not defined.\n";
> #endif
>     return 0;
> }
>
>
> This fails with:
>
> huh.cpp: In function int main():
> huh.cpp:6:48: error: expected primary-expression before << token
>      std::cout << "_ILP32 macro is [" << _ILP32 << "]\n";
>
> Is anyone else seeing this issue with g++? This program compiles ok on 
> RHEL and outputs that _ILP32 is not defined.
>
> If I change the cryptopp header config.h bit to read:
> #if defined(__x86_64__) && ((__ILP32__ >= 1) || defined(_ILP32))
>
> then the problem goes away. This indicates to me that it is a bug in 
> cryptopp-585 in that one is not supposed to use or test the macro value for 
> _ILP32, only that it is defined.
>

Using __ILP32__ and _ILP32  in an '#if' like above is legal C and C++ The 
preprocessor is supposed to replace it with the value 0 if its not defined. 
Also see http://stackoverflow.com/q/5085392.

Using __ILP32__ and _ILP32 in the C++ program `cout << _ILP32` is not legal 
because __ILP32__ and _ILP32 are not defined. Here, 'not legal' is 
contingent upon a non-X32 system. Effectively __ILP32__ and _ILP32 are 
undeclared identifiers because they escape the preprocessor.

CentOS 5 uses GCC 4.8 but it did not witness the problem. My two Solaris 
11.3 machines with GCC 4.8.2 do not witness it either (see below).

If its breaking a compile then its our bug. We'll get something checked-in 
to address it.

Jeff

----------

$ uname -a
SunOS solaris 5.11 11.3 i86pc i386 i86pc

$ g++ --version
g++ (GCC) 4.8.2

$ CXX=g++ gmake
g++ -DNDEBUG -g2 -O2 -fPIC -march=native -m64 -Wa,--divide -pipe -c 
cryptlib.cpp
g++ -DNDEBUG -g2 -O2 -fPIC -march=native -m64 -Wa,--divide -pipe -c cpu.cpp
...

32-bit does not produce the error:

$ CXX=g++ gmake CXXFLAGS="-DNDEBUG -g2 -O2 -fPIC -m32 -pipe"
g++ -DNDEBUG -g2 -O2 -fPIC -m32 -pipe -c cryptlib.cpp
g++ -DNDEBUG -g2 -O2 -fPIC -m32 -pipe -c cpu.cpp
...

I see 32-bit builds have other problems a little further into the make 
process. It looks like the inline assembler is broken, but I'll need to 
investigate it further.

-- 
-- 
You received this message because you are subscribed to the "Crypto++ Users" 
Google Group.
To unsubscribe, send an email to cryptopp-users-unsubscr...@googlegroups.com.
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 cryptopp-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to