Skip site navigation (1) Skip section navigation (2)

Re: [PATCH] Symbol restriction and versioning

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Martijn van Oosterhout <kleptog(at)svana(dot)org>
Cc: pgsql-patches(at)postgresql(dot)org
Subject: Re: [PATCH] Symbol restriction and versioning
Date: 2005-10-24 17:27:15
Message-ID: 200510241727.j9OHRF325833@candle.pha.pa.us (view raw or flat)
Thread:
Lists: 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(at)svana(dot)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(at)candle(dot)pha(dot)pa(dot)us               |  (610) 359-1001
  +  If your life is a hard drive,     |  13 Roberts Road
  +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073

In response to

pgsql-patches by date

Next:From: Bruce MomjianDate: 2005-10-24 18:09:04
Subject: Re: [PATCHES] Caveat for Domains
Previous:From: Bruce MomjianDate: 2005-10-24 15:38:17
Subject: Re: Will PQregisterThreadLock() be documented?

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group