To get totally off topic and talk about programming (8-))...

PK writes:

> Some more notes on version numbers:
> 
> 	- major version numbers need not be bumped unless you change an
> 	  *existing* interface to the library in an incompatible way (eg.
> 	  the recent change to _ctype_).
> 
> 	- minor version numbers can be incremented if something has been
> 	  *added* to the library interface. This will not break existing
> 	  binaries. However, new programs using the new stuff will likely
> 	  break if run with older shared libraries.
> 	  [warning: there is currently no such message as "xxx: older
> 	  revision than expected"].

I am curious as to whether or not this allows you to use "strip" against
a program linked against a shared library or not; the implication in
being able to add things to the library is that the GOT doesn't change
symbol order, and new symbols occur later in the table (at least with my
implementation).

It seems that for the ld.so approach (which is what would buy you the
ability to have a "partially matched" library), you have to keep around
the symbol table in a global (you appear to) to allow stripped executables
-- but then shared referenced objects would not, technically, be "stripped"
if you kept the symbols around.  Is the ability to not update minor versions
on an interface extension worth the extra cost?  My impression was that
major revs occur on *any* interface change, and minor revs are only for
bug fixes without an interface change.

It's possible that this may not be a problem for you, depending on the
way you actually utilize globals -- is there something we should be
aware of regarding global variables in libraries being referenced by
programs (and globals in programs being referenced in libraries)?  The
second is apparently disallowed [sorry for not doing my homework and
finding this out from the code itself].

Just an aside, but did you consider using the data vs. text tags in a
PIC compiled standard library with a seperate GOT to avoid the split
into two files (.a vs. .sa+.so), and if so, why did you avoid it?  I
assume that you did and the answer will be to allow duplicate data
pages [potentially unchanged by the app] to exist in a library?  If
so, I would think it would take a library with a relatively large amount
of data to equal the symbols kept in the binary -- but then again, this
could add up quickly with a lot of libraries (then again, the symbols
being kept around for X have got to be a bear...).


					Regards,
					Terry Lambert
					terry@cs.weber.edu
---
Any opinions in this posting are my own and not those of my present
or previous employers.

------------------------------------------------------------------------------