Archived

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

Ice 3.3 build fails on Solaris 8 (Sparc), maybe due to posix changes

Hi,

some old posts on these forums suggested that Ice ought to work on Solaris 8, even though it isn't officially supported. So I went through the pain of downloading and building all the third party libraries required by Ice 3.3 without problems, but when I tried to build Ice itself, it complained about a call to a non-existent posix function call:
Cond.cpp: In constructor `IceUtil::Cond::Cond()':
Cond.cpp:311: error: `CLOCK_MONOTONIC' was not declared in this scope
Cond.cpp:311: error: `pthread_condattr_setclock' was not declared in this scope
Cond.cpp:311: warning: unused variable 'CLOCK_MONOTONIC'
Cond.cpp:311: warning: unused variable 'pthread_condattr_setclock'

Searching the forums for this function I found this post which suggests that the change (monotonic clock support) was introduced in version 3.3.
Does this mean I might have better luck with an older version of Ice, or can someone suggest a simple change to make this work (or proceed to the next compilation error :rolleyes: ) for Solaris 8 for Sparc? Can anyone report on versions of Ice that they have been able to compile cleanly on this platform?
Note that I've used g++ with gcc 3.4.6, which is what worked ok on the third-party libraries.
Any advice much appreciated

Comments

  • bernard
    bernard Jupiter, FL
    Hi Graham,

    I recommend looking at this thread:

    http://www.zeroc.com/forums/help-center/3900-building-ice-3-3-0-red-hat-9-a.html

    Another port to port Ice to an old platform. It even covers this problem!

    So, I'd try to adjust a few #ifdef in the Ice source code to build on Solaris 8.

    Also, check that /dev/random and /dev/urandom are present on your system (if not, install the corresponding Solaris patch).

    Best regards,
    Bernard
  • Hi Bernard,

    thanks for the pointer. I did find this thread but wasn't sure if a fix for Red Hat would also be a fix for Solaris. I'm generally wary of simply excluding troublesome code from the build when I don't know what the consequences are. Anyway, I tried ifdef'ing it out and this brought me to the complementary place in Time.cpp, where I had to do something similar to use the alternative to CLOCK_MONOTONIC.
    After that, all of IceUtil was built successfully and it went on to building slice. All modules were compiled ok but when it came to building libSlice.so.3.3.0, I got an error:
    Text relocation remains                         referenced
        against symbol                  offset      in file
    <unknown>                           0x20b8      /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6/../../../libmcpp.a(directive.o)
    <unknown>                           0x20bc      /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6/../../../libmcpp.a(directive.o)
    ...(100s of similar lines)
    
    It looks like I didn't build mcpp in a compatible way. I built mcpp after using
    ./configure --enable-mcpplib --disable-shared
    
    where configure found and used gcc 3.4.6, i.e. the same gcc suite as I'm using to build Ice, but it looks like there is still some incompatibility.
    I think I may have to knock this on the head. It was one of those "if it's easy we'll do it, if it's trouble we won't" kind of jobs, so it's looking like the latter.

    I still think Ice still looks promising for other applications under consideration but supporting this legacy platform looks like too much hard work.
  • xdm
    xdm La Coruña, Spain
    Hi Graham,

    I think your latest problem is because you have disabled mcpp shared library try to build mcpp without disabled it.

    Bests,
    José
  • xdm
    xdm La Coruña, Spain
    Hi Graham,

    I was not totally correct in my previous post --disable-shared should work, but -KPIC should also be enabled.

    From our ThirdParty-Sources REAME. this is the recommended way to configure mcpplib
    ./configure CC=cc CXX=CC CFLAGS=-KPIC --enable-mcpplib --disable-shared
      (and --prefix=<dir> if you like)
    

    Lets us know if you still have problems.

    Bests,
    José
  • Hi José,

    Ahh, thanks for this advice. I guess I'm showing my ignorance here. I did get the configure options from the README, but since I'm using gcc rather than Sun cc I had just blindly omitted the compiler options. Having just tried again I've also found that KPIC is a Sun CC-ism. I'm assuming that -fPIC is the direct gcc equivalent, and having rebuilt mcpp with this option, the libSlice build has succeeded and the build is continuing. I'll let you know the outcome, but thanks for helping me over these initial hurdles.
    cheers,
    Graham
  • Update:
    I've found a few more Third Party libraries were not set up to the satisfaction of the Ice build. The README doesn't show any special instructions for building bzip2 for Solaris, but I found I had to modify the Makefile to add -fPIC to CFLAGS, due to the same link error that mcpp had suffered. After that, bzip2 was happy. Then it fell over for IceSSL, where the same old fPIC chestnut reared its ugly head. At this point I decided to remove IceSSL from the src Makefile rather than rebuild yet another library.
    I then had to remove the Freeze components also, because I got this:
    g++ -c -I.. -I../../include -DFREEZE_API_EXPORTS    -ftemplate-depth-128 -Wall -D_REENTRANT -fPIC -g BackgroundSaveEvictorI.cpp
    In file included from /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6/../../../../include/c++/3.4.6/backward/iostream.h:31,
                     from /usr/local/include/db_cxx.h:59,
                     from ../Freeze/TransactionI.h:15,
                     from ../Freeze/ObjectStore.h:18,
                     from ../Freeze/EvictorI.h:16,
                     from ../Freeze/BackgroundSaveEvictorI.h:13,
                     from BackgroundSaveEvictorI.cpp:10:
    /usr/local/lib/gcc/sparc-sun-solaris2.8/3.4.6/../../../../include/c++/3.4.6/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <iostream> instead of the deprecated header <iostream.h>. To disable this warning use -Wno-deprecated.
    In file included from ../Freeze/TransactionI.h:15,
                     from ../Freeze/ObjectStore.h:18,
                     from ../Freeze/EvictorI.h:16,
                     from ../Freeze/BackgroundSaveEvictorI.h:13,
                     from BackgroundSaveEvictorI.cpp:10:
    /usr/local/include/db_cxx.h:60:23: exception.h: No such file or directory
    In file included from ../Freeze/TransactionI.h:15,
                     from ../Freeze/ObjectStore.h:18,
                     from ../Freeze/EvictorI.h:16,
                     from ../Freeze/BackgroundSaveEvictorI.h:13,
                     from BackgroundSaveEvictorI.cpp:10:
    /usr/local/include/db_cxx.h:1069: error: expected class-name before '{' token
    gmake[2]: *** [BackgroundSaveEvictorI.o] Error 1
    

    Then Icebox failed to build because of this:
    g++   -ftemplate-depth-128 -Wall -D_REENTRANT -fPIC -g -L../../lib  -o ../../bin/icebox ServiceManagerI.o Service.o -lIceBox  -lIce -lIceUtil -lpthread
    Undefined                       first referenced
     symbol                             in file
    libiconv_close                      ../../lib/libIce.so
    libiconv_open                       ../../lib/libIce.so
    libiconv                            ../../lib/libIce.so
    ld: fatal: Symbol referencing errors. No output written to ../../bin/icebox
    collect2: ld returned 1 exit status
    gmake[2]: *** [../../bin/icebox] Error 1
    
    even though the libiconv package (SMCliconv 1.11) is installed in /usr/local/lib.

    At this point I removed a slew of product names from the subdirectory Makefiles, leaving just Ice, IceUtil and Slice in the hope that a basic Ice installation could be salvaged. This has also fallen over in the test subdirectory when trying to build "client", again due to the libiconv problem mentioned above. I manually appended the -liconv flag in test/Slice/keyword/Makefile and this seems to be what it wanted. This really needs to go somewhere in Make.rules, but probably somewhere in the "do not modify" section. Or perhaps even in Make.common.rules. The same problem with the missing linker flag arises for all the demo programs, so I'll try to find somewhere in the make rules to make this universal.

    Actually, looking at Make.rules, perhaps instead of rebuilding the third party libraries with -fPIC, would it not have been better to disable GENPIC here for building Ice, or would that have opened another can of worms?
  • bernard
    bernard Jupiter, FL
    Hi Graham,

    The best solution to the iconv problem is to define ICONV_LIB in Make.rules.SunOS. See Make.rules.Darwin for an example. Another possibility is to remove the dependency on iconv in the Ice library (by editing src/Ice/StringConverter.cpp).

    With Solaris 10, you can use the bzip library that ships with Solaris, but I am not sure for Solaris 8.

    For Berkeley DB, it looks like you didn't configure or build DB properly. Please refer to the README in the third-party source distribution for build instructions.

    You should also keep the PIC support -- the Ice build system supports only shared libraries.

    Cheers,
    Bernard
  • Hi Bernard,

    thanks for the quick reply. Yes, I found Make.rules.SunOS but I had just added -liconv to BASELIBS (which worked) until I saw your post. I didn't know that ICONV_LIB existed, so I've done what you've said and it's still happy.
    I don't think I'll go back to rebuilding db46 if it's only needed by Freeze. Likewise, many of the other extended features of ICE are things I probably don't need. It would be nice if the make process was a bit more 'modular', so that it would be easier to build just the core feature set first, then build extra components such as Freeze, Glacier etc. when required. This would also cut down on the number of third party libraries that need to be configured properly.

    I think the main difference with Solaris 10 is that Sun decided to remove static kernel libraries and made the whole kernel use shareable objects to provide a more hygenic kernel interface. This probably means that Solaris 10 libraries all use PIC by default. But I'm just guessing.

    regards,
    Graham

    p.s. another bit of user feedback is that this forum has a shockingly short login duration. By the time I've typed a message ready to post, I find that I've been logged out again!
  • Grrraham wrote: »
    p.s. another bit of user feedback is that this forum has a shockingly short login duration. By the time I've typed a message ready to post, I find that I've been logged out again!

    Neither myself nor any of my colleagues has ever observed this problem. Perhaps you have some special settings in your Web browser, such as cookies disabled?
  • Hi all,

    well, thanks to all your help, I've now got the core Ice features built and gmake test succeeds for all tests in IceUtil, Slice and Ice. One last hurdle was that there is obviously a minimum version number for Python that is used to run the test suite. The INSTALL.SOLARIS just says "Python is required" (probably all you need to say for the supported Solaris 10 platform). However, the Solaris 8 distribution included a 7 year-old Python 1.5, which didn't even recognise its own language! Downloaded Python 2.5 and all was well.

    Now that I've run gmake install and got it in the <prefix> directory, can I simply tar up this directory and copy it to put the same build on another machine? How many of the third party libraries do I also need to copy install to just use basic messaging (i.e. not using ICEssl or Freeze etc.)?

    marc wrote: »
    Neither myself nor any of my colleagues has ever observed this problem. Perhaps you have some special settings in your Web browser, such as cookies disabled?
    Nothing special, but I didn't select "remember me" to save my login data in a cookie.
  • dwayne
    dwayne St. John's, Newfoundland
    The only third party library you should need to copy for just basic messaging is the bzip2 library.