Re: SIGSEGV taken on 8.1 during dump/reload - Mailing list pgsql-hackers

From Martijn van Oosterhout
Subject Re: SIGSEGV taken on 8.1 during dump/reload
Date
Msg-id 20051113151907.GB29373@svana.org
Whole thread Raw
In response to Re: SIGSEGV taken on 8.1 during dump/reload  (Kevin Brown <kevin@sysexperts.com>)
Responses Re: SIGSEGV taken on 8.1 during dump/reload  (Kevin Brown <kevin@sysexperts.com>)
List pgsql-hackers
On Sat, Nov 12, 2005 at 10:46:33PM -0800, Kevin Brown wrote:
> Hmm...but isn't the version number also something that can be stored
> in the shared library itself during link time (e.g., via the -soname
> option to the linker)?  The manpage for ld under Linux implies that
> this will cause the executable that's linked against the shared object
> to look explicitly for a library with the soname specified by the
> shared object.  I don't know if that just causes the dynamic linker to
> look for a file with the specified soname or if it will actually
> examine the shared object under consideration to make sure it has the
> DT_SONAME field in question, however.

No, that's completely unrelated. The soname is what gets put in the
DT_NEEDED field of programs that need it. Thus if you have
libtermcap.so symlinked to libncurses.so, when you link with -ltermcap,
the linker will include a reference to libncurses because that's what
the soname is. The only place version numbers come in is when a library
libfoo.8.2 has a soname libfoo.8 which means that at runtime it will
accept any lib with that soname.

None of this applies to PostgreSQL because we open the modules
directly, and don't rely on the linker loader.

Hope this helps,
--
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.

pgsql-hackers by date:

Previous
From: Gregory Maxwell
Date:
Subject: Re: MERGE vs REPLACE
Next
From: Tom Lane
Date:
Subject: Re: Multi-table-unique-constraint