OpenSolaris

Solaris Libraries & APIs

See the ARC Library Policy for additional requirements.

Assure that libraries on which you depend have a sufficient stability classification. dump -Lv tells you what you depend on directly. ldd tells you what you depend on directly or indirectly. You'll have to search your source code to find libraries loaded via dlopen(3x), though. With what linker -R options will your components be linked (to find libraries not in /usr/lib in their defautlt installation location)?
Do you depend on any static libraries? Dynamic libraries are strongly preferred over static because they

• • allow applications to obtain future library improvements--bug fixes and performance improvements--without relinking,
  • reduce swapspace consumption and paging, and
  • reduce diskspace consumption.

Versioning
Each library must be named with a version suffix, both in its filename (a link without it is traditional) and via the -h argument built into the library. This is so a future incompatible change--if necessary--can be recognized.
Review the Solaris 2.5 (or later) Linker and Libraries Guide especially the Versioning chapter in particular. The committee recommends performing explicit versioning and reducing symbol scope to "hide" symbols that clients need not see. (A scoped library can even run on Solaris 2.4. But if users must link against the library on Solaris 2.4, ld will give a warning unless the library was linked with the -z noversion option or the ld patch is installed on 2.4.)
Without symbol versioning, each library should contain interfaces only of the same commitment level. Otherwise, users of the Standard or Stable portion will be inconvenienced when the version is bumped to reflect changes to the less-stable portion.

Other Library Guidelines
Use the -R flag when linking to unbundled libraries (not in /usr/lib), rather than depending on users to set LD_LIBRARY_PATH. Build your library with -ztext to assure position-independent code and -zdefs so you'll know if any references are unresolvable, indicating an unexpressed dependency (typically, on libc) but possibly simply an erroneous reference. Make dependencies explicit via -l options when building the library.
Unless you're shipping the .o files, use strip(1) to remove the symbol table or strip -x to remove the bulky debugging info that is useless without the .o files. You should probably use mcs -d -a to leave a single identification comment or at least mcs -c to merge redundant ones.
C++ implementation and interfaces are more problematic since the GNU C++ compiler does not support a Stable ABI across compiler versions, while the Sun Studio C++ compiler does.
Documentation: Provide a manpage or the like for each function, plus one manpage for the whole library, which names the file(s) to #include, gives the linking instructions, and perhaps enumerates the public interfaces.
Libraries for Solaris should be designed to function in any locale, and should be "large file aware" (meaning able to use files larger than 2GB, per PSARC/1995/289/).