[Please CC any replies, thanks]

NOTE: I am not requesting that this patch is integrated, only that it
exists in the archive in case future problems emerge requiring it. It's
essentially something that only works for Linux and select other OSes
and the bug it fixes is somewhat outside the scope of the PostgreSQL
community (see below).

This patch:
a) When building a shared library on Linux and an exports.txt file
exists, it will generate an appropriate version script for ld to limit
the symbols exported.

b) Additionally, if SHLIB_VERSION is defined in the Makefile, the
symbols of the library will be versioned with that version.

The net effect is that the exported symbol list from libpq (the only
lib with an exports file) drops from 216 symbols to the 123 listed as
exports.

The bug I'm referring to is somewhat theoretical in that I don't think
anyone's run into it, but you never know. Say someone starts with
Debian Unstable today and installs postgresql-8.0 and libnss-pgsql1.
The former is linked against libpq4, the latter against libpq3 but they
have largely the same symbols. The user then configures libnss-pgsql
for hostname lookups and starts psql to connect to a remote server.

psql then does a gethostbyname which goes via NSS to dlopen
libnss-pgsql and its symbols will be linked against libpq4 because
they're already loaded. Any remaining symbols will be resolved against
libpq3. Finally, any global symbols in libpq3 that have a symbol of the
same name in libpq4 will be resolved against the version in libpq4. I
don't think I need to explain that this situation may have undefined
results.

Note: rpath won't save you hare since that applies to finding
libraries, but doesn't affect symbol lookup order. The above will also
apply if above user compiles their own version of postgresql but not
libnss-pgsql.

Symbol versioning solves this in that each library and program will
link to the version it expects. This patch paves the way. And if the
user deletes the other library in an attempt to make it work, they get
a helpful message like:

./psql: $PATH/libpq.so.4: version `LIBPQ_4.1' not found (required by ./psql)

Note, this is the only reason I would expect it to be adopted by core,
for debugging purposes. The only time versioning may cause
incompatabilities is if different distributions start versioning the
same library differently. Unversioned binaries work against versioned
libs and vice-versa.

Hence, we should at least get straight the tags. I suggest:

LIBPQ_$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) eg: LIBPQ_4.1

This is in line with how other libraries do it (eg GLIBC_2.0) and
provides maximum differentiation. It's not like we're trying to provide
any kind of backward compatability at that level.

This patch will work on any system using GNU ld and where the system
dynamic linker supports versioned symbols. The only one I'm sure of is
Linux but others are easily added.

Thanks for your attention,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> tool for doing 5% of the work and then sitting around waiting for someone
> else to do the other 95% so you can sue them.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQFDVTiCIB7bNG8LQkwRAnk3AJ9lgjC0bnWzDzUpfptDH2 07vblqPwCghBZm
TgcyxNTxiwI+RWBDF7iNd9A=
=KId4
-----END PGP SIGNATURE-----

This has been saved for the 8.2 release:

http://momjian.postgresql.org/cgi-bin/pgpatches_hold

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

Martijn van Oosterhout wrote:
-- Start of PGP signed section.
> [Please CC any replies, thanks]
>
> NOTE: I am not requesting that this patch is integrated, only that it
> exists in the archive in case future problems emerge requiring it. It's
> essentially something that only works for Linux and select other OSes
> and the bug it fixes is somewhat outside the scope of the PostgreSQL
> community (see below).
>
> This patch:
> a) When building a shared library on Linux and an exports.txt file
> exists, it will generate an appropriate version script for ld to limit
> the symbols exported.
>
> b) Additionally, if SHLIB_VERSION is defined in the Makefile, the
> symbols of the library will be versioned with that version.
>
> The net effect is that the exported symbol list from libpq (the only
> lib with an exports file) drops from 216 symbols to the 123 listed as
> exports.
>
> The bug I'm referring to is somewhat theoretical in that I don't think
> anyone's run into it, but you never know. Say someone starts with
> Debian Unstable today and installs postgresql-8.0 and libnss-pgsql1.
> The former is linked against libpq4, the latter against libpq3 but they
> have largely the same symbols. The user then configures libnss-pgsql
> for hostname lookups and starts psql to connect to a remote server.
>
> psql then does a gethostbyname which goes via NSS to dlopen
> libnss-pgsql and its symbols will be linked against libpq4 because
> they're already loaded. Any remaining symbols will be resolved against
> libpq3. Finally, any global symbols in libpq3 that have a symbol of the
> same name in libpq4 will be resolved against the version in libpq4. I
> don't think I need to explain that this situation may have undefined
> results.
>
> Note: rpath won't save you hare since that applies to finding
> libraries, but doesn't affect symbol lookup order. The above will also
> apply if above user compiles their own version of postgresql but not
> libnss-pgsql.
>
> Symbol versioning solves this in that each library and program will
> link to the version it expects. This patch paves the way. And if the
> user deletes the other library in an attempt to make it work, they get
> a helpful message like:
>
> ./psql: $PATH/libpq.so.4: version `LIBPQ_4.1' not found (required by ./psql)
>
> Note, this is the only reason I would expect it to be adopted by core,
> for debugging purposes. The only time versioning may cause
> incompatabilities is if different distributions start versioning the
> same library differently. Unversioned binaries work against versioned
> libs and vice-versa.
>
> Hence, we should at least get straight the tags. I suggest:
>
> LIBPQ_$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION) eg: LIBPQ_4.1
>
> This is in line with how other libraries do it (eg GLIBC_2.0) and
> provides maximum differentiation. It's not like we're trying to provide
> any kind of backward compatability at that level.
>
> This patch will work on any system using GNU ld and where the system
> dynamic linker supports versioned symbols. The only one I'm sure of is
> Linux but others are easily added.
>
> Thanks for your attention,
> --
> Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a
> > tool for doing 5% of the work and then sitting around waiting for someone
> > else to do the other 95% so you can sue them.

[ Attachment, skipping... ]
-- End of PGP section, PGP failed!

--
Bruce Momjian | http://candle.pha.pa.us
pgman@candle.pha.pa.us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073

---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

http://www.postgresql.org/docs/faq