Re: Cleaning up multiply-defined-symbol warnings on OS X - Mailing list pgsql-patches

From Martijn van Oosterhout
Subject Re: Cleaning up multiply-defined-symbol warnings on OS X
Date
Msg-id 20060509084138.GA29652@svana.org
Whole thread Raw
In response to Re: Cleaning up multiply-defined-symbol warnings on OS X  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: Cleaning up multiply-defined-symbol warnings on OS X  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-patches
On Tue, May 09, 2006 at 10:19:56AM +0200, Peter Eisentraut wrote:
> Am Samstag, 29. April 2006 21:27 schrieb Martijn van Oosterhout:
> > What it does is remove the restriction that any one program can only
> > use (directly or indirectly) one version of libpq at any moment.
> > Programs can use indirectly postgres via PAM or NSS or other such
> > pluggable interfaces. Currently PAM and NSS must be using the same
> > version of libpq as any program that might call them or everything
> > blows up.
>
> Symbol versioning only helps if a function's signature has changed, doesn't
> it?  Have we ever done that?

Depends what you mean by signature. The structures of PGconn and
PGresult have changed over time, so if you you pass a PGresult
allocated by libpq4 to a function in libpq3, it'll crash.

Symbol versioning can serve a few purposes:

1. You can have one library supporting several ABIs simultaneously.
glibc does this but that's not what we're interested in.

2. When loading a library, the linker checks both the symbol name and
the symbol version. Thus, it allows two versions of the same library to
co-exist in the same address space simultaneously. This is what we
want.

Basically, if you symbol version, a program compiled against a
particular version with only call functions in that version and won't
be accedently misdirected to another version that happened to be loaded
first...

In the example I posted earlier, say psql starts, compiled against
libpq5. It does a gethostbyname() that is redirected to an NSS module
originally compiled against libpq4. The linker will load libpq4 but
link the actual symbols of the NSS module to libpq5. Any it can't find
there it will find in libpq4. It's this splitting up that will get you.

Loading this way round is unlikely to cause many problems since we
don't tend to remove functions from the API so it may not link any
symbols to libpq4. The more dangerous situation is if the old library
gets loaded first and something uses symbols that didn't exist in the
old version but do in the new version.

Have a nice day,
--
Martijn van Oosterhout   <kleptog@svana.org>   http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

Attachment

pgsql-patches by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Have configure complain about unknown options
Next
From: "Marko Kreen"
Date:
Subject: Re: Have configure complain about unknown options