Re: SIGSEGV taken on 8.1 during dump/reload
От | Kevin Brown |
---|---|
Тема | Re: SIGSEGV taken on 8.1 during dump/reload |
Дата | |
Msg-id | 20051113064633.GA29881@filer обсуждение исходный текст |
Ответ на | Re: SIGSEGV taken on 8.1 during dump/reload (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: SIGSEGV taken on 8.1 during dump/reload
|
Список | pgsql-hackers |
Tom Lane wrote: > On the other hand, it'd be relatively easy for clueless lusers to > defeat; I can readily imagine someone copying foo.so.8.2 to foo.so.8.3 > when the backend complained that it couldn't find the latter. So > maybe it's not what we want. 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. -- Kevin Brown kevin@sysexperts.com
В списке pgsql-hackers по дате отправления: