We use the default OS compiler g++ 8.3, are you installing zeroc-ice packages from the debian repository or from a different source?
Do you have any more info about the failures?
You can try running the 3.7 test suite against the binary distribution to check if everything works
git clone [email protected]:zeroc-ice/ice.git
make ICE_BIN_DIST=all CONFIGS=cpp11-shared V=1
ICE_BIN_DIST=all python allTests.py --config=cpp11-shared --all
We regularly run all tests on debian armhf and arm64 platforms and are not aware of any issues that affect the C++11 mapping, there is a known issue that affects the C++ 98 mapping but shouldn't matter for your case as you are using the C++11 mapping.https://doc.zeroc.com/ice/3.7/release-notes/known-issues-and-platform-notes#id-.KnownIssuesandPlatformNotesv3.7-C++98Mappingand-stdoptiononLinuxARM
Please don't post the same question in different threads is difficult to follow up, your application is crashing because std::system_error is not being handled, you should run the application with a debugger and check the stack traces when this happens.
I'm afraid this stack doesn't provide a lot of information. Which Linux operating system do you use? Could you install the debug files? Can you easily reproduce the problem with a debugger?
To install the debug files:
sudo apt-get install libzeroc-ice3.7-dbgsym
sudo yum install ice-debuginfo
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 the ice/cpp directory (to build the C++98 mapping)? And then try to run make 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"?
make print V="supported-platforms supported-configs"
There is no support for modifying the process PATH in IceBox, a third option will be to distribute icebox.exe and in its dependencies with your application and run everything from the application folder.
After starting the configured services, it activates the service manager adapter if "IceBox.ServiceManager.Endpoints" was set, and then prints ready message if "IceBox.PrintServicesReady" was set, once that is done it return control to Ice::Service class that will notify Windows that the service was started.
Did you check icebox.exe is run with --service?
sc qc icebox
[SC] QueryServiceConfig SUCCESS
TYPE : 10 WIN32_OWN_PROCESS
START_TYPE : 2 AUTO_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:\Program Files\ZeroC\Ice-3.7.4\bin\icebox.exe --Ice.Config=D:\3.7.4\ice-demos\cpp98\IceBox\hello\config.icebox --service icebox
TAG : 0
DISPLAY_NAME : IceBox Server
SERVICE_START_NAME : NT Authority\LocalService
Check the BINARY_PATH_NAME and make sure --service argument is there
Also try setting IceBox.PrintServicesReady and see if the ready message is in the log, this will indicate that IceBox start correctly.
The configuration file format doesn't allow for setting a property to a multi-line string, you can create a property set by calling createProperties and the use setProperty as needed.
You didn't miss something, there's currently no way to set this at the topic or subscriber level, it's a global IceStorm configuration. The queue size max configuration was designed as a protection for IceStorm to avoid consuming too much memory if a client doesn't consume its events or not fast enough.
Can't you set this property to a value large enough to satisfy all the subscribers? Or do you want to rely on this property to unsubscribe or drop events events for slow subscribers automatically?
As a workaround, you could instantiate different IceStorm service instances in the same IceBox server with different configurations but I understand that it's not ideal.
Note that we also released recently a new service called DataStorm, you might want to take a look at it as well.
Ice cannot directly send your named tuples, you have to use types defined in Slice, here you can probably use a couple of structs and sequences like in:
long Data; // Send date as a long
There is no __copyFrom in 3.7 seems you still have some object files from your 3.5 build