Craig James <craig_james@emolecules.com> writes:
> On 8.3.10 and earlier, Postgres would ONLY load this library if we put it in /usr/local/pgsql/lib, so I figured it
wasa security restriction, that Postgres altered the LD_LIBRARY_PATH to ensure that only legitimate, admin-approved
librariescould be loaded. The Postgres documentation sort of hints at this but doesn't give details.
> Is this true, that Postgres restricts the dynamic linker in some way?
No, it is not. Library searching behavior is whatever the platform's
dynamic linker defines it to be. On some platforms we try to build the
executables with an "rpath" pointing at the PG lib directory, so that
you don't need to explicitly configure anything to load our libraries
--- but I don't believe that that causes the linker to *only* search
that directory on any of those platforms. (If it did, you'd have big
problems with libc.so for instance.)
As for LD_LIBRARY_PATH, the only part of our code that touches that is
the regression test wrapper pg_regress. You might or might not find
this relevant:
http://archives.postgresql.org/pgsql-hackers/2010-05/msg00248.php
My guess is that the reason you had to put libopenbabel.so into
/usr/local/pgsql/lib before is precisely that you hadn't modified
/etc/ld.so.conf, and so only /usr/local/pgsql/lib would be searched
(as a result of the postgres executable's rpath property) plus the
standard system libraries (but unless you ran ldconfig, the linker
wouldn't know about any additions there). The Ubuntu situation may
or may not be similar --- in particular, I don't know whether their
packages even set the rpath property at all. I think some distros
deprecate using rpath and instead expect the PG lib directory to
be part of the ldconfig configuration, in which case *no* nonstandard
library is gonna get found unless you ask ldconfig to pretty please
find it. Or maybe Ubuntu has yet another way. You really ought to
ask for help about this in an Ubuntu-specific forum.
regards, tom lane