Archived

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

Building Solaris 10 with Gcc tool chain.

I need to build Ice libraries with gcc on Solaris 10. We are using Gnu tool chain for a lot of other libraries and it is too hard to port everything to use SunPro compilers. I managed to do this for Solaris 9 with no problem but I'm getting the following errors using Gcc 3.4.6 on Sol10:

/cots/sol10-port/lib/gcc/sparc-sun-solaris2.10/3.4.6/../../../../sparc-sun-solaris2.10/bin/ld: ../../lib/libIceUtil.so: pthread_cond_signal: invalid version 4 (max 0)
../../lib/libIceUtil.so: could not read symbols: Bad value
collect2: ld returned 1 exit status

Comments

  • benoit
    benoit Rennes, France
    Hi John,

    I found the following link regarding a similar issue:

    Nabble - Gnu - Binutils - Bugs - [Bug ld/6431] New: ld says: invalid version 3 (max 0)

    It looks like the solution is to remove the -lpthread option from the linker options on Solaris 10.

    Cheers,
    Benoit.
  • Removed -pthread and still not working.

    I removed '-pthread' from the Make.rules.SunOS and did make clean then started over. This time it says "Invalid version 2 (max 0)"
    g++ -shared -L../../lib -o ../../lib/libSlice.so.3.3.1 -h libSlice.so.33 Scanner.o ../Slice/Grammar.o Parser.o CPlusPlusUtil.o CsUtil.o JavaUtil.o Preprocessor.o Checksum.o PythonUtil.o DotNetNames.o RubyUtil.o Util.o FileTracker.o MD5.o MD5I.o -lIceUtil -L/program/seeker1c_sac/cots/sol10/local/lib -lmcpp
    /cots/sol10-port/lib/gcc/sparc-sun-solaris2.10/3.4.6/../../../../sparc-sun-solaris2.10/bin/ld: ../../lib/libIceUtil.so: pthread_mutexattr_destroy: invalid version 2 (max 0)
    ../../lib/libIceUtil.so: could not read symbols: Bad value
    collect2: ld returned 1 exit status
    make[3]: *** [../../lib/libSlice.so.3.3.1] Error 1
    make[3]: Leaving directory `/tilde/basraij/work/seeker/Ice-3.3.1/cpp/src/Slice'

    benoit wrote: »
    Hi John,

    I found the following link regarding a similar issue:

    Nabble - Gnu - Binutils - Bugs - [Bug ld/6431] New: ld says: invalid version 3 (max 0)

    It looks like the solution is to remove the -lpthread option from the linker options on Solaris 10.

    Cheers,
    Benoit.
  • Problem solved.

    I found the issue. Turns out that I didn't update that paths correctly in Make.rules and it was trying to link with Solaris9 versions of Ice shared objects which will not work. The error messages issued by the linker where not very helpful however.

    Thanks for your help.
  • bernard
    bernard Jupiter, FL
    Hi John,

    It's good to see that you're making progress!

    Note that you may not need to build everything with GCC -- it's a good test, but it could also take more time.

    You only need to build with GCC the libraries you will link with, namely IceUtil, Ice, possibly IceSSL, Freeze and client libraries for IceStorm / IceGrid etc. (depending on what your application needs). For everything else (the Slice library, slice2cpp, the IceGrid service, the IceStorm service etc.), you could keep using the Sun CC binaries we provide together with your GCC application.

    Best regards,
    Bernard
  • bernard
    bernard Jupiter, FL
    I just built IceUtil, Ice, IceSSL and the hello demo with GCC 3.4.3 on Solaris 10 (using the binary distribution for slice2cpp) and everything appears to work fine. I didn't even need to remove -lpthread in the hello demo.

    The build system required only very minor updates (set CXX=g++ in Make.rules.SunOS, and comment out the LD_LIBRARY_PATH setting in Make.common.rules).

    I hope you won't encounter any further problem with this GCC port!

    Best regards,
    Bernard
  • My concern with your approach is that you will have mixed binaries. The ones from distribution (icegrid, slice2java etc) that require .so's (icestorm.so, IceUtil etc) built by SunPro compiler and our apps which require .so's that are built using the gnu compiler. This would be difficult to deploy and the libs would get mixed causing confusion. So I thinking that we still need to rebuild everything from sources.

    However I'm still not able to recreate what I did in a new directory starting with source files unpacked from the source distribution. I get the same link errors as before.

    What I now have is a source tree that I can rebuild at will (my original one) but I can't create a new one from scratch. This is not a good situation to be in. It will work for now but I need to come back to this issue soon.

    I tried building my application with SunCC 5.9 and found out that it is missing many STL features compared to gnu so it would not be easy to port to that. I'm amazed that you guys were able to use that compiler at all. Unless mine is old.

    CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25
    bernard wrote: »
    I just built IceUtil, Ice, IceSSL and the hello demo with GCC 3.4.3 on Solaris 10 (using the binary distribution for slice2cpp) and everything appears to work fine. I didn't even need to remove -lpthread in the hello demo.

    The build system required only very minor updates (set CXX=g++ in Make.rules.SunOS, and comment out the LD_LIBRARY_PATH setting in Make.common.rules).

    I hope you won't encounter any further problem with this GCC port!

    Best regards,
    Bernard
  • bernard
    bernard Jupiter, FL
    My concern with your approach is that you will have mixed binaries. The ones from distribution (icegrid, slice2java etc) that require .so's (icestorm.so, IceUtil etc) built by SunPro compiler and our apps which require .so's that are built using the gnu compiler. This would be difficult to deploy and the libs would get mixed causing confusion.

    True, there is a potential for confusion, and I was just suggesting this as a short term solution.

    Deployment would not be all that difficult if you take advantage of embedded run-path, and don't use LD_LIBRARY_PATH for locating libraries. E.g. you would put all the Ice / Sun CC libraries in /opt/Ice-3.3/lib (that's the run path embedded in programs such as icegridregistry) and all Ice / GCC libraries and your own libraries would be in their own separate directory.
    I tried building my application with SunCC 5.9 and found out that it is missing many STL features compared to gnu so it would not be easy to port to that. I'm amazed that you guys were able to use that compiler at all. Unless mine is old.

    CC: Sun C++ 5.9 SunOS_sparc Patch 124863-01 2007/07/25

    That's the version we use. The issue is the default standard library included with this compiler: in order to maintain binary compatibility with earlier versions of CC, Sun disabled many features!

    Sun also provides an alternate standard library for CC, STLPort, that would probably work better for your application ... however, you would also need to rebuild Ice with this non-default library, since our binary distribution is built with the default standard library.

    Best regards,
    Bernard