Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4
От | Craig Ringer |
---|---|
Тема | Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4 |
Дата | |
Msg-id | 4869F3AE.7090402@postnewspapers.com.au обсуждение исходный текст |
Ответ на | Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4 (askel <dummy666@mail.ru>) |
Ответы |
Re: Re: problem getting postgres 8.3.1 with xml support to work on Redhat Enterprise Linux 4
|
Список | pgsql-general |
askel wrote: > On Jun 27, 5:46 pm, t...@sss.pgh.pa.us (Tom Lane) wrote: >> Linux isn't real friendly to putting shared libraries outside the >> standard directories. If you want to keep libxml2.so in its own directory >> you'll need to teach the dynamic linker to look there. See ldconfig. > > What could be more friendly than providing few ways to specify where > to look for shared libraries? rpath linking, so the executable can have relative (or at least on some systems absolute) paths to libraries "burned in" at link time. At least recent-ish versions of the GNU toolchain do support rpath during linking, and the dynamic linker from glibc can use the rpath information. The CMake build system supports rpath linking automatically on Linux. I don't know about libtool or about libtool-free autotools build environments. The manpage for GNU ld has some information on rpath linker options. rpath linking is particularly useful when you want an app to use a private copy of a library built differently to how the rest of the system needs that library to be built. You don't want it to be on the general library search path, so without rpath you generally land up having to resort to wrapper scripts. -- Craig Ringer
В списке pgsql-general по дате отправления: