[csw-maintainers] Solaris 10 revision suppport?

James Lee james at opencsw.org
Mon Apr 30 13:21:16 CEST 2012

What is the CSW support for the revisions of Solaris 10?

This page:

says "Solaris 10 is fully supported." which isn't true as CSWorbit2
2.14.19,REV=2011.12.08 doesn't work with Solaris 10U4.  Either we
consider this a bug and fix it or CSW is only supported on certain
revisions of Solaris 10, either way I'm happy but if taking the latter it
would help to explain this better, that is at a minimum change the above
web page.

** A Failure **

$ soffice
ld.so.1: soffice.bin: fatal: libresolv.so.2: version `SUNW_2.2.2' not
found (required by file /opt/csw/lib/sparcv8/libORBit-2.so.0)
ld.so.1: soffice.bin: fatal: libresolv.so.2: open failed: No such file or
ld.so.1: soffice.bin: fatal: relocation error: file
symbol gnome_vfs_initialized: referenced symbol not found

This problem is not limited to CSWorbit2 but potentially affects any
linkage to versioned symbols present on the build machines but not on the
client's OS.

** Explanation **

libresolv.so.2 has versioned symbols and libORBit-2.so.0 requires
version SUNW_2.2.2 which is not present in Solaris 10U4.  U6 works.  I
don't have quick access to U5, maybe someone will please check U5.

Check the versions, examples run on a new system:

$ /usr/ccs/bin/elfdump -v /opt/csw/lib/libORBit-2.so.0.1.0

Version Needed Section:  .SUNW_version
            file                        version
            libpthread.so.1             SUNW_1.2
            libresolv.so.2              SUNW_2.2.2
            libnsl.so.1                 SUNW_1.7
            libsocket.so.1              SUNW_1.4
            libc.so.1                   SUNW_0.7

$ /usr/ccs/bin/elfdump -v /lib/libresolv.so.2

Version Definition Section:  .SUNW_version
     index  version                     dependency
       [1]  libresolv.so.2                                   [ BASE ]
       [2]  SUNW_2.2.2                  SUNW_2.2.1
       [3]  SUNW_2.2.1                  SUNW_2.2
       [4]  SUNW_2.2                    SUNW_2.1
       [5]  SUNW_2.1
       [6]  SUNWprivate_2.2             SUNWprivate_2.1
       [7]  SUNWprivate_2.1


** Workaround **

Use old orbit:

** Solutions **

1. Link with a mapfile and select a universal version.  This means users
don't take advantage of whatever a new version brings.

2. Link twice, once normally and then with a mapfile and do something
clever based on the OS.

3. Build on a low rev machine.  Probably not acceptable, eg, cc 12.3
might not run.

4. Clients update Solaris.  For this to be acceptable do the following:
 + Change support statement in the user guide
 + packages that need specific updates or patches use baulking
   checkinstall scripts.
 + (suggestion) pkgutil to check the OS update in addition to
   checkinstall.   checkinstall is the correct place but pkgutil can
   provides early detections and prevent a failed partial update.


More information about the maintainers mailing list