Archived
Building both C++98 and C++11 libraries
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.
Comments
-
Hi Pascal,
Ice 3.5.1 is quite old and we don't really support it anymore other than for commercial projects that still depend on it. I'm not surprised it doesn't build with recent OpenSSL APIs. When Ice 3.5.1 was released, it supported OpenSSL 0.9.8. The release notes which include build instructions and supported platforms are accessible from the Ice 3.5 download page: https://zeroc.com/downloads/ice/3.5
Do you have a specific need for Ice 3.5? I really recommend to use the latest Ice 3.7 version instead.
For Ice 3.7, the release notes are also accessible from the download page: https://zeroc.com/downloads/ice/3.7 but we moved the "Build from Sources" instructions to the GitHub source tree instead in the README.md file of each language mapping directory.
For C++, see the build instructions are here https://github.com/zeroc-ice/ice/blob/3.7/cpp/README.md
The C++ source tree provides two different C++ mappings for Ice, the C++98 mapping and the C++11 mapping. It also supports different build configurations (static, shared for Unix platforms, xcodesdk for macOS). On supported platforms, you can view the different build configurations by executing
$ make print V=supported-configs
You can then build multiple configurations/platforms using make. For example, on Linux to build both the C++98 and C++11 mapping with shared libraries:
$ make CONFIGS="shared cpp11-shared"
The "shared" build configuration is to build the default C++98 mapping and the "cpp11-shared" configuration is to build the C++11 mapping. Our CI build Ice from sources everyday on our supported platforms, so I'm confident it still works
Note that you don't have to specify
-DICE_CPP11_MAPPING
when building Ice sources. You only need to specify this when building your programs against Ice (we use the same set of header files for both the C++98 and C++11 mapping and this macro allows to pick the C++11 version of the headers when building your program).I believe some of the 3.7 build errors you got are caused by specifying the ICE_CPP11_MAPPING macro.
If you are not using a supported platform, can you try to run
make
in theice/cpp
directory (to build the C++98 mapping)? And then try to runmake CONFIGS=cpp11-shared
(to build the C++11 mapping)? There's no need to clean between the two builds. Can you provide the errors you get from running these two build steps?Can you provide information on the Linux distribution and the compiler version that you are using when build Ice sources? What is the output of
make print V="supported-platforms supported-configs"
?Cheers,
Benoit.5 -
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.
Pascal0 -
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,
Benoit0