FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Wed, Feb 05, 2003 at 10:00:54AM +0100, Frediano Ziglio wrote:

> > Well, gcc and the Linux ELF loader support per-symbol versioning, which
> > is what's allowed glibc to not bump its SO version in over five years in
> > spite of many, /many/ changes.  But not every platform supports symbol
> > versioning (only Linux and FreeBSD that I'm aware of), so I've had a
> > hard time convincing people to adopt the non-portable technique... :)

> Another solution is to maintain old functions if we remove one, do not
> update so version if we add a function and change so version only when
> change a function prototype or behavior (difficult cause prototype and
> behavior are defined by Sybase and Microsoft for all high levels 
> libraries). So a solution is to add a DBTDS function to dblib and
> downgrade so version...

I think the usual reason for changing prototypes is that we had them
wrong in the first place. :)  E.g., wrong argument types (sizes).
However, there are also things like the recent renumbering of CT-Lib
constants that also change the ABI.

I think there'll be enough of this kind of thing for the foreseeable
future that, without versioned symbols, there won't be many cases where
it's advantageous to keep deprecated symbols around from one release to
the next.

> There is a portable solution to define the set of function library
> should export?

Nope -- hence my comment above.  Ulrich Drepper has a nice (draft) paper
that talks about the portability of various symbol-hiding and
symbol-versioning solutions, but I can't find it at the moment...  I
recommend it to anyone interested in such library portability issues --
if you can find it. :)

-- 
Steve Langasek
postmodern programmer

Attachment: pgpcwPwrK2Pjh.pgp
Description: PGP signature