On Mar 16, 2007, at 12:19 PM, Chaskiel M Grundman wrote:
You should be aware that symbol versioning does not do this on
solaris.
the notion of a library being able to export symbols with the same
name and different versions pointing at different addresses is a
gnu LD extension (<http://www.linuxshowcase.org/2000/2000papers/
papers/browndavid/browndavid_html/>. section 4.1 discusses the
capabilities of sun and gnu LD. section 4.2 explains sun's
versioning policy, and why they don't need the multiple-versions
capability: once a function is considered 'public', sun never
changes its function signature)
...and here's the scoop on that:
http://docs.sun.com/app/docs/doc/817-4415/6mjum5shb?a=view
Quote:
The Solaris link editor and run-time linker use two kinds of library
versioning: file versioning and symbol versioning. In file
versioning, a library is named with an appended version number, such
as libc.so.1. When an incompatible change is made to one or more
public interfaces in that library, the version number is incremented
(for example, to libc.so.2). In a dynamically linked application, a
symbol bound to at build time might not be present in the library at
run time. In symbol versioning, the Solaris linker associates a set
of symbols with a name. The linker then checks for the presence of
the name in the library during run-time linking to verify the
presence of the associated symbols.
/dale
--
Dale Ghent
UNIX and Storage Systems Specialist
UMBC - Office of Information Technology
ENG 201 - 410-443-1705
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
