Home Help Center

Building both C++98 and C++11 libraries

pelahipelahi Member Pascal ElahiOrganization: Pawsey Supercomputing CentreProject: Radio Astronomy where data acquisition uses ICE

I am very new to building ICE from scratch on linux machines. I am trying to build both libraries of ice >=3.7 and 3.5.1 but am running into compilation issues.

First, I have not been able to find appropriate compilation instructions anywhere. It is not clear how to compile both versions other than editing the config/Make.rules to point to the appropriate install directories, only select cpp and run

make 
make install 
make clean
make CXXFLAGS=-DICE_CPP11_MAPPING
make install 

However, this seems a terrible way of building these libraries. Is there not something I can set in the config/Make.rules or provide to make so both are built? Something along the lines of

make cpp_types=(CPP98 CPP11)

Is there useful documentation somewhere?

Second, in trying to compiling 3.7.4 and 3.7.2 and 3.5.1 with -DICE_CPP11_MAPPING I am running into a whole host of bugs in the code.

>=3.7

For example in 3.7.4

Compiling [amd64-static] src/slice2js/Gen.cpp
src/slice2js/Gen.cpp: In constructor ‘Slice::Gen::Gen(const string&, const std::vector<std::__cxx11::basic_string<char> >&, const string&, bool)’:
src/slice2js/Gen.cpp:638:57: error: invalid cast to abstract class type ‘Slice::FileException’
  638 |         throw FileException(__FILE__, __LINE__, os.str());
      |                                                         ^
In file included from src/slice2js/Gen.cpp:12:
src/Slice/FileTracker.h:14:7: note:   because the following virtual functions are pure within ‘Slice::FileException’:
   14 | class FileException : public ::IceUtil::Exception
      |       ^~~~~~~~~~~~~
In file included from include/IceUtil/Handle.h:8,
                 from src/Slice/Parser.h:9,
                 from src/slice2js/JsUtil.h:8,
                 from src/slice2js/Gen.h:8,
                 from src/slice2js/Gen.cpp:8:
include/IceUtil/Exception.h:105:24: note:       ‘virtual IceUtil::Exception* IceUtil::Exception::ice_cloneImpl() const’
  105 |     virtual Exception* ice_cloneImpl() const = 0;
      |                        ^~~~~~~~~~~~~
src/slice2js/Gen.cpp:656:61: error: invalid cast to abstract class type ‘Slice::FileException’
  656 |             throw FileException(__FILE__, __LINE__, os.str());
      |                                                             ^
src/slice2js/Gen.cpp: In member function ‘virtual bool Slice::Gen::TypesVisitor::visitClassDefStart(const ClassDefPtr&)’:
src/slice2js/Gen.cpp:1333:80: error: ‘constMemFun’ is not a member of ‘IceUtil’
 1333 |     transform(allBases.begin(), allBases.end(), back_inserter(ids), ::IceUtil::constMemFun(&Contained::scoped));
      |                                                                                ^~~~~~~~~~~
make[1]: *** [Makefile:26: src/slice2js/build/x86_64-linux-gnu/static/Gen.o] Error 1

This seems to be quite a bug and will occur throughout the build. This error is also present in 3.7.2

There are even other errors, such as the one in cpp/src/IcePatch2Lib/Util.cpp

IcePatch2Internal::writeFileInfo(FILE* fp, const LargeFileInfo& info)
 {
     int rc = fprintf(fp, "%s\t%s\t" ICE_INT64_FORMAT "\t%d\n",
                     escapeString(info.path, "", IceUtilInternal::Compat).c_str(),
                      bytesToString(info.checksum).c_str(),
                      info.size,
                      static_cast<int>(info.executable));
...

The IceUtilInternal::Compact is incorrect and must be IceUtilInternal::ToStringMode::Compat. This bug seems surprising to me since any CI would clearly pick it up.

Given the large number of bugs present in the C++11 build I am wondering if I am taking the wrong approach and not all sources need to be compiled with -DICE_CPP11_MAPPING.

3.5.1

I am encountering quite different set of errors in 3.5.1 which is not even compiling without the CPP11 flag.

make[3]: Entering directory '/home/ela017/myresearch/codes/radio-codes/ice-3.5.1/cpp/src/IceSSL'
g++ -c -I.. -I../../include -DICE_SSL_API_EXPORTS  -m64 -Wall -Werror -pthread -fPIC -O2 -DNDEBUG Instance.cpp
Instance.cpp: In function ‘DH* IceSSL_opensslDHCallback(SSL*, int, int)’:
Instance.cpp:145:86: error: invalid use of incomplete type ‘SSL’ {aka ‘struct ssl_st’}
  145 |     IceSSL::Instance* p = reinterpret_cast<IceSSL::Instance*>(SSL_CTX_get_ex_data(ssl->ctx, 0));
      |                                                                                      ^~
In file included from /usr/include/openssl/crypto.h:25,
                 from /usr/include/openssl/comp.h:16,
                 from /usr/include/openssl/ssl.h:17,
                 from ../IceSSL/UtilF.h:17,
                 from ../IceSSL/Instance.h:14,
                 from Instance.cpp:15:
/usr/include/openssl/ossl_typ.h:148:16: note: forward declaration of ‘SSL’ {aka ‘struct ssl_st’}
  148 | typedef struct ssl_st SSL;
      |                ^~~~~~
Instance.cpp: In function ‘int IceSSL_opensslVerifyCallback(int, X509_STORE_CTX*)’:
Instance.cpp:154:86: error: invalid use of incomplete type ‘SSL’ {aka ‘struct ssl_st’}
  154 |     IceSSL::Instance* p = reinterpret_cast<IceSSL::Instance*>(SSL_CTX_get_ex_data(ssl->ctx, 0));
      |                                                                                      ^~
In file included from /usr/include/openssl/crypto.h:25,
                 from /usr/include/openssl/comp.h:16,
                 from /usr/include/openssl/ssl.h:17,
                 from ../IceSSL/UtilF.h:17,
                 from ../IceSSL/Instance.h:14,
                 from Instance.cpp:15:
/usr/include/openssl/ossl_typ.h:148:16: note: forward declaration of ‘SSL’ {aka ‘struct ssl_st’}
  148 | typedef struct ssl_st SSL;
      |                ^~~~~~
Instance.cpp: In constructor ‘IceSSL::Instance::Instance(const CommunicatorPtr&)’:
Instance.cpp:278:20: error: ‘RAND_egd’ was not declared in this scope; did you mean ‘RAND_add’?
  278 |                 if(RAND_egd(entropyDaemon.c_str()) <= 0)
      |                    ^~~~~~~~
      |                    RAND_add
make[3]: *** [../../config/Make.rules:339: Instance.o] Error 1

I am not certain what to make of this error (I'm using OpenSSL 1.1) but it does appear to be that 3.5.1 requires a very specific version of OpenSSL. Given this is the case, is there a reason ICE does not move to something like CMAKE? That would greatly help building this code from source.

Best Answer

Answers

  • pelahipelahi Member Pascal ElahiOrganization: Pawsey Supercomputing CentreProject: Radio Astronomy where data acquisition uses ICE

    Hi Benoit, thanks for the help, I had not realised all the info regarding build was in cpp/README.md. I would suggest that the main README.md point to this file, clearly indicating that instructions for compiling the code is locate there. Also, would it not be useful to have this information on the source download page?

    Regarding 3.5.1, the issue is that the software using the ice libraries produced errors with versions later than 3.5.0 (which is very old). We still have 3.5.0 source so we can go from there but I am going to try and address the bug that was seen in 3.5.1 and also see if it is present in later versions of ICE. I will likely start a new discussion when I can get the software stack built using different, newer, versions of ICE. I will try compiling 3.5.1 with older OpenSSL versions.

    And for reference, it does appear that the 3.7 build errors are a result of naively appling ICE_CPP11_MAPPING but that does appear to be an issue since that macro shouldn't result in build errors. Perhaps these issues will be addressed in later versions of ICE.

    If I have further questions regarding the build I will post here and if I run into issues using the library I will start a new discussion.

    Thanks for the help.
    Pascal

  • benoitbenoit Rennes, FranceAdministrators, ZeroC Staff Benoit FoucherOrganization: ZeroC, Inc.Project: Ice ZeroC Staff

    Hi Pascal,

    Actually, building code that doesn't support the C++11 mapping with the ICE_CPP11_MAPPING would definitely cause an error given that the C++11 mapping header definitions are quite different from the C++98 mapping ones. So it's not a bug, we have some code in the C++ source tree that only support the C+-98 mapping (our Slice translators for instance). See our C++ mappings documentation: https://doc.zeroc.com/ice/3.7/language-mappings

    Building your Ice 3.5.0 based application with 3.5.1 shouldn't be an issue as we maintain binary compatibility between Ice minor versions. If you are not using IceSSL, you might be able to skip the building of this library.

    Cheers,
    Benoit

Sign In or Register to comment.