This forum has been archived. Please start a new discussion on GitHub.

Building Ice-3.3.0 on Red Hat 9

I have openssl-0.9.8g installed, but get the following error during make in the cpp directory. Clues welcome:

make[2]: Entering directory `/home/philip/Ice-3.3.0/cpp/src/IceSSL'
/usr/local/gcc/4.3.1/bin/c++ -c -I.. -I../../include -DICE_SSL_API_EXPORTS -ftemplate-depth-128 -Wall -D_REENTRANT -I/usr/include/nptl -I/usr/kerberos/include -I//usr/local/ssl/include -fPIC -g Instance.cpp
Instance.cpp: In function ‘long unsigned int IceSSL_opensslThreadIdCallback()’:
Instance.cpp:76: error: invalid static_cast from type ‘__opaque_pthread*’ to type ‘long unsigned int’
make[2]: *** [Instance.o] Error 1
make[2]: Leaving directory `/home/philip/Ice-3.3.0/cpp/src/IceSSL'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/philip/Ice-3.3.0/cpp/src'
make: *** [all] Error 1


  • matthew
    matthew NL, Canada
    Sorry, this isn't a supported platform. For a full list of supported platforms see

    For this particular problem, assuming you can't upgrade to supported version of Linux, and you need the SSL plug-in, you can probably use the reinterpret_cast from the previous code block.
    unsigned long
    #if defined(_WIN32)
        return static_cast<unsigned long>(GetCurrentThreadId());
    #elif defined(__FreeBSD__) || defined(__APPLE__) || defined(__osf1__)
        // On some platforms, pthread_t is a pointer to a per-thread structure.
        return reinterpret_cast<unsigned long>(pthread_self());
    #elif (defined(__linux) || defined(__sun) || defined(__hpux)) || defined(_AIX)
        // On Linux, Solaris, HP-UX and AIX, pthread_t is an integer.
        return static_cast<unsigned long>(pthread_self());
    #   error "Unknown platform"

    Note that you might well run into further problems down the road, however!
  • De-selecting SSL plugin

    I don't need the SSL plugin, but I can't see how to unselect it. Is it somewhere in config/Make.rules.Linux ?
  • dwayne
    dwayne St. John's, Newfoundland
    If you don't want to compile SSL, edit cpp/src/Makefile and remove IceSSL from the list of subdirectories to compile.
  • No IceBox.h file in tarball

    Thanks, that was a big help.

    Next hurdle:

    make[3]: Entering directory `/home/philip/Ice-3.3.0/cpp/test/IceBox/configuration'
    make[3]: *** No rule to make target `../../../include/IceBox/IceBox.h', needed by `Service.o'. Stop.

    Looks like editing items out of cpp/src/Makefile disrupted dependency resolution. Solved by changing directory to src/IceBox and running make there.
  • mes
    mes California

    IceBox.h is generated as part of the build process, but you have to build the cpp/src/IceBox subdirectory.

    As you can see, if you are building only certain portions of the Ice source distribution, you will encounter build failures elsewhere in the tests and demos that depend on the components you've skipped.

    Take care,
  • Another compile error

    I reported that Freeze/BackgroundSaveEvictorI.cpp gave a compilation error. Some further Googling gave me the answer - the '--enable-cxx' option must be provided when building BerkeleyDB.4.6. Hopefully, this will help someone else, too.
  • bernard
    bernard Jupiter, FL
    Hi Philip,

    When building Ice from source, I recommend reading the INSTALL.<OS> for your system, for example INSTALL.LINUX.

    Another useful file is the README in the third-party source distribution available from our download page. It describes in particular the requirements for Berkeley DB.

    Although INSTALL.LINUX points to this third-party source distribution, I agree that some build failures can be confusing. Maybe a FAQ entry would help?

  • README in Third Party sources tarball

    You're right, I shouldn't have missed that.

    For the next Ice release, it might be worth having the tarball set to unpack into a subdirectory, so that important files don't get overlooked in cluttered home directories... :-)

    It's very encouraging to get such helpful responses.
  • Successful build, but 'make test' fails

    *** running tests 2/61 in /home/philip/Ice-3.3.0/cpp/test/IceUtil/thread
    *** configuration: Default
    *** test started: 09/04/08 08:11:16
    starting client... ok
    running mutex test... Cond.cpp:314: IceUtil::ThreadSyscallException:
    syscall exception: Invalid argument failed
    test mutex failed
    ('test in /home/philip/Ice-3.3.0/cpp/test/IceUtil/thread failed with exit status', 256)
  • bernard
    bernard Jupiter, FL
    If you look at the corresponding code (line 314 in IceUtil/Cond.cpp), you'll see the issue:
    #if !defined(__hpux) && !defined(__APPLE__)
        rc = pthread_condattr_setclock(&attr, CLOCK_MONOTONIC); 
        if(rc != 0)
            throw ThreadSyscallException(__FILE__, __LINE__, rc);

    It looks like condition variables on Red Hat 9 don't support a monotonic clock, at least not with the standard POSIX API. You should ifdef this out on your system as well.

  • Next test failure

    Skipping test 8/61, I found the failure message for 9/61 indicated the problem was the lack of the epoll() system call. Undefining ICE_USE_EPOLL in src/Ice/Selector.h fixed the problem with 9/61, and 8/61 also. Onward...
  • Test 61/61, "Servname not supported for ai_socktype"

    1 thru 60 all pass, 61 gives:

    *** running tests 61/61 in /home/philip/Ice-3.3.0/cpp/test/Glacier2/staticFiltering
    *** configuration: Default
    *** test started: 09/05/08 16:10:50
    testing category filter..Network.cpp:346: Ice::DNSException:
    DNS error: Servname not supported for ai_socktype
    . DNS error: Servname not supported for ai_socktype
    /home/philip/Ice-3.3.0/cpp/test/Glacier2/staticFiltering/client: Network.cpp:1387: Ice::DNSException:
    DNS error: Servname not supported for ai_socktype
    ('test in /home/philip/Ice-3.3.0/cpp/test/Glacier2/staticFiltering failed with exit status', 256)
  • benoit
    benoit Rennes, France

    Most likely this failure occurs when using an empty -h option in endpoints. You can try to reproduce it with the hello demo, the hello client should throw a similar exception. It should work if you add "-h localhost" to the endpoints of the Hello.Proxy in the demo/Ice/hello/config.client file. To workaround this problem, you can try replacing:
                rs = getaddrinfo(0, "1", &hints, &info);

                rs = getaddrinfo(0, 0, &hints, &info);

    in the src/Ice/Network.cpp file, line 335 and 1365.

  • Solved getaddrinfo(3) issue

    Thanks for the guidance, Benoit.

    I now recall having problems with getaddrinfo(3) on RH9 a couple of years ago - it doesn't behave quite the same as current implementations.

    Your suggestion of setting the 'service' parameter to 0 didn't fix the problem, but setting it to "tcpmux" did.

    Now I have all 61 tests passing for 'cpp'. :-)

    Next up: 'py'!
  • 'py' test 1 fails

    $ make test
    ../config/Make.common.rules:111: Found slice2py in both ICE_HOME/bin and ./../cpp/bin, ICE_HOME/bin/slice2py will be used!

    *** running tests 1/19 in /home/philip/Ice-3.3.0/py/test/Slice/keyword
    *** configuration: Default
    *** test started: 09/08/08 15:04:46
    starting client... ok
    ('test in /home/philip/Ice-3.3.0/py/test/Slice/keyword failed with exit status', 256)

    $ gdb /usr/bin/python /home/philip/Ice-3.3.0/py/test/Slice/keyword/core.*
    #0 0x4048469f in IceUtil::SimpleShared::__decRef() (this=0xa3be4)
    at Shared.h:70
    70 assert(_ref > 0);

    (gdb) bt
    #0 0x4048469f in IceUtil::SimpleShared::__decRef() (this=0xa3be4)
    at Shared.h:70
    #1 0x409855b9 in ~Handle (this=0xbffee910) at Handle.h:186
    #2 0x4098cf06 in Contained (this=0x813b3e4, __vtt_parm=0x40a7d238,
    container=@0xbffeea70, name=@0x819848c) at Parser.cpp:472
    #3 0x4099de60 in Module (this=0x813b3a8, container=@0xbffeea70,
    name=@0x819848c) at Parser.cpp:2273
    #4 0x4098e1bc in Slice::Container::createModule(std::string const&) (
    this=0x819f29c, name=@0x819848c) at Parser.cpp:531
    #5 0x4097763f in slice_parse() () at Grammar.y:233
    #6 0x409b46f8 in Slice::Unit::parse(std::string const&, _IO_FILE*, bool, Slice::FeatureProfile) (this=0x819f1d0, filename=@0xbfffdfe0, file=0x815e4a0,
    debug=false, profile=Ice) at Parser.cpp:5504
    #7 0x4048388f in IcePy_loadSlice (args=0x4017ed2c) at Slice.cpp:148
    #8 0x080ed814 in PyCFunction_Call (func=0x40194d0c, arg=0x4017ed2c,
    kw=0xbffee910) at Objects/methodobject.c:108
    #9 0x080a4f1b in call_function (pp_stack=0xbfffe22c, oparg=670692)
    at Python/ceval.c:3445
    #10 0x080a33e0 in eval_frame (f=0x815c134) at Python/ceval.c:2122
    #11 0x080a3f26 in PyEval_EvalCodeEx (co=0x4017f1e0, globals=0xa3be4,
    locals=0x4013379c, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0,
    defcount=0, closure=0x0) at Python/ceval.c:2669
    #12 0x080a64b2 in PyEval_EvalCode (co=0x4017f1e0, globals=0x4013379c,
    locals=0x4013379c) at Python/ceval.c:537
    #13 0x080cbb01 in run_node (n=0x4011c338, filename=0xbffff9b2 "",
    globals=0x4013379c, locals=0x4013379c, flags=0xbfffe388)
    at Python/pythonrun.c:1267
    #14 0x080cb365 in PyRun_SimpleFileExFlags (fp=0x8129d08,
    filename=0xbffff9b2 "", closeit=1, flags=0xbfffe388)
    at Python/pythonrun.c:862
    #15 0x08054d32 in Py_Main (argc=0, argv=0xbfffe404) at Modules/main.c:415
    #16 0x080548ab in main (argc=3, argv=0xbfffe404) at Modules/python.c:23
    #17 0x42015704 in __libc_start_main () from /lib/tls/
    Current language: auto; currently c++
  • benoit
    benoit Rennes, France

    It sounds like an unexpected exception is being thrown in the Slice::Contained constructor and this is causing a crash because of missing __setNoDelete calls in the constructor (see this FAQ for the reason).

    Could you wrap the constructor code (in cpp/src/Slice/Parser.cpp line 459) with the following and try again after recompiling the Slice library:

    This should allow the exception to propagate and be displayed by the parser and hopefully give you more clues on the reason why the parsing fails.

  • Changing __setNoDelete had no effect

    Inspecting IceUtil/Shared.h seems to indicate that

    70: assert(_ref > 0);

    is failing. This is unaffected by the value of _noDelete.

    I'm trying a code change to comment out the assert(), and return instead. However, I'm concerned this may be hiding a deeper problem...
  • benoit
    benoit Rennes, France

    Yes, this assert doesn't look good. Which gcc version do you use?

    Did you try to translate the py/test/Slice/keyword/ manually with slice2py? Does it work? You could also try to run other tests or some of the demos.

    Also, which python version do you use on your platform? Did you build it yourself?

  • Python tests pass


    Thanks for the hint - I have multiple versions of Python on the system, and had configured the wrong one.

    All 19 tests now pass!

    Thanks, everyone, for the patient help.