FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Wed, Feb 05, 2003 at 12:08:43PM -0500, Castellano, Nicholas wrote:
> The following entry points were removed between BRANCH0_60 and HEAD of
> libsybdb.  By a strict interpretation of rule 6 in the libtool info
> documentation, AGE should be set to 0, and we get a major version bump as a
> result.

Ok.  I think this can go either way; most of the functions you list are
not made available in the sybdb headers, and any that are were clearly
never intended to be public entry points.  If someone thinks there's a
danger someone may be using some of these functions from libsybdb, I have
no objection to bumping the soname -- but I also don't think this is
enough of an issue that I'm going to do it myself.

> Since we pull in all of libtds, the following removed libtds entry points
> were also removed from libsybdb:
> tds7_send_login
> tds_add_input_param
> tds_alloc_config
> tds_free_column
> tds_free_config
> tds_get_config
> tds_get_ntstring
> tds_is_control
> tds_is_doneinproc
> tds_is_end_of_results
> tds_is_error
> tds_is_fixed_token
> tds_is_message
> tds_is_result_row
> tds_is_result_set
> tds_msg_get_proc_name
> tds_msleep
> tds_process_column_row
> tds_process_env_chg
> tds_reset_msg_info
> tds_send_login
> tds_strtok_r
> tds_write_packet

Is there any reason for not dynamically linking dblib (et al.) against
libtds, so tds-related ABI bumps can be unequivocally avoided?  I thought
I'd seen motion in this direction at various points in the past, but my
latest build shows libsybdb.so is statically linked against libtds.

-- 
Steve Langasek
postmodern programmer

Attachment: pgpJGgDpdo4BR.pgp
Description: PGP signature