Re: [PATCH] Symbol restriction and versioning - Mailing list pgsql-patches

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