On 7/15/10 2:14 PM, Tom Lane wrote:
Craig James<craig_james@xxxxxxxxxxxxxx> 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 was a security restriction, that Postgres altered the LD_LIBRARY_PATH to ensure that only legitimate, admin-approved libraries could 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.
Thanks, you answer helped but in an unexpected way. Knowing it had nothing to do with dynamic loading made me look elsewhere, so I dug around with nm(1) and realized that the missing symbol really was missing.
The reason is because of changes in pgxs.mk, the makefile that's supposed to help build extensions. In 8.3, I could override the link step and use g++ rather than gcc, but in 8.4 the pgxs.mk ignored my link step, and was using gcc for the linking. Since the OpenBabel chemistry library is written in C++, you have to use g++ to do the link step for the Postgres extension.
I ended up hand crafting a Makefile and not using pgxs.mk at all, and now everything works.
Craig
--
Sent via pgsql-admin mailing list (pgsql-admin@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
