Explicit LOAD and dynamic library loading
Hello,
I'm working on two extensions, call them "foo" and "bar". bar depends on
some of the functions defined in foo. They are both built from a single
Makefile, just vanilla PGXS:
MODULES = foo bar
EXTENSION = foo bar
### etc. ###
As bar depends on foo, that's specified in its .control file, and CREATE
EXTENSION works just fine with foo created first, then bar.
However, whenever I run one of the UDTs defined in bar, I get this error
message:
dev=# SELECT * FROM test1 WHERE (info(bar_dat)).some_prop = 10;
ERROR: could not load library
"/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so":
/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so: undefined symbol:
foo_func1
I have to explicitly load foo:
dev=# LOAD 'foo.so';
Then everything works. What am I missing?
Thanks.
Stephen Scheck <singularsyntax@gmail.com> writes:
However, whenever I run one of the UDTs defined in bar, I get this error
message:
dev=# SELECT * FROM test1 WHERE (info(bar_dat)).some_prop = 10;
ERROR: could not load library
"/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so":
/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so: undefined symbol:
foo_func1
I'm betting an rpath problem. Is this a Linux-oid system? What does
"ldd /vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so" say? Is there
any option to set rpath in the link command for bar.so?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
Tom,
Not sure what you mean by "oid" system:
[postgres@dev1 lib]$ uname -a
Linux dev1 2.6.35.14-106.fc14.x86_64 #1 SMP Wed Nov 23 13:07:52 UTC 2011
x86_64 x86_64 x86_64 GNU/Linux
[postgres@dev1 lib]$ ldd bar.so
linux-vdso.so.1 => (0x00007fff1c7ff000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa4c96ac000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa4c9c5d000)
pinguinito:~/sandbox/postgresql-9.2.4 sscheck$ head -10 config.log
This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.
It was created by PostgreSQL configure 9.2.4, which was
generated by GNU Autoconf 2.63. Invocation command line was
$ ./configure --prefix=/home/sscheck/sandbox/postgresql-9.2.4-build
--enable-debug CFLAGS=-O0
You'll have to bear with me, I'm not well versed in the subtleties of
rpath, shared vs. static linking, etc. (actually almost completely
ignorant). Looking at configure help though "--disable-rpath" is not
present...
After digging into the PGXS docs a bit more, I think if I change the
Makefile a bit this may work:
MODULES = foo bar
MODULE_big = bar
OBJS = bar.o
SHLIB_LINK = foo.o
Thanks for taking a look at this.
-Steve
On Wed, Jun 12, 2013 at 8:08 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Stephen Scheck <singularsyntax@gmail.com> writes:
However, whenever I run one of the UDTs defined in bar, I get this error
message:dev=# SELECT * FROM test1 WHERE (info(bar_dat)).some_prop = 10;
ERROR: could not load library
"/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so":
/vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so: undefined symbol:
foo_func1I'm betting an rpath problem. Is this a Linux-oid system? What does
"ldd /vol/data/home/postgres/pg-builds/9.2.4/lib/bar.so" say? Is there
any option to set rpath in the link command for bar.so?regards, tom lane
Stephen Scheck <singularsyntax@gmail.com> writes:
[postgres@dev1 lib]$ ldd bar.so
linux-vdso.so.1 => (0x00007fff1c7ff000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa4c96ac000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa4c9c5d000)
So you're missing any reference to foo.so; not surprising it fails.
You need to make sure that "-lfoo" or something similar gets into the
link command for bar.so. You might still have some rpath issues after
that, but right now the runtime linker doesn't even know it should be
loading foo.so.
After digging into the PGXS docs a bit more, I think if I change the
Makefile a bit this may work:
MODULES = foo bar
MODULE_big = bar
OBJS = bar.o
SHLIB_LINK = foo.o
Oh, you're trying to build two separate shlibs in one Makefile? I don't
think that our Makefile infrastructure is smart enough to handle that,
at least not if cross-references are required. You'd probably be well
advised to split them into two separate source-code directories.
Another question worth asking yourself, if you are building like this,
is why you're bothering with two .so's at all. Is there a strong reason
not to just make them into one library?
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
I modified the Makefile a bit and it all works now:
MODULES = foo
MODULE_big = bar
OBJS = bar.o foo.so
EXTENSION = foo bar
One thing that's still a bit confusing, though ... I build the extensions
in my own home dir, which results in the rpath getting set like
this: -Wl,-rpath,'/vol/data/home/sscheck/sandbox/postgresql-9.2.4-build/lib'
But I do "make install" from the same directory, but logged in as the
postgres user under which I run my server(s). Does the rpath get embedded
into the .so's? If so I don't see why it works, but it does...
Thanks!
-Steve
On Thu, Jun 13, 2013 at 7:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Show quoted text
Stephen Scheck <singularsyntax@gmail.com> writes:
[postgres@dev1 lib]$ ldd bar.so
linux-vdso.so.1 => (0x00007fff1c7ff000)
libc.so.6 => /lib64/libc.so.6 (0x00007fa4c96ac000)
/lib64/ld-linux-x86-64.so.2 (0x00007fa4c9c5d000)So you're missing any reference to foo.so; not surprising it fails.
You need to make sure that "-lfoo" or something similar gets into the
link command for bar.so. You might still have some rpath issues after
that, but right now the runtime linker doesn't even know it should be
loading foo.so.After digging into the PGXS docs a bit more, I think if I change the
Makefile a bit this may work:MODULES = foo bar
MODULE_big = bar
OBJS = bar.o
SHLIB_LINK = foo.oOh, you're trying to build two separate shlibs in one Makefile? I don't
think that our Makefile infrastructure is smart enough to handle that,
at least not if cross-references are required. You'd probably be well
advised to split them into two separate source-code directories.Another question worth asking yourself, if you are building like this,
is why you're bothering with two .so's at all. Is there a strong reason
not to just make them into one library?regards, tom lane
Stephen Scheck <singularsyntax@gmail.com> writes:
One thing that's still a bit confusing, though ... I build the extensions
in my own home dir, which results in the rpath getting set like
this: -Wl,-rpath,'/vol/data/home/sscheck/sandbox/postgresql-9.2.4-build/lib'
Hm, it should be .../lib under whatever you configured the installation
prefix directory to be.
regards, tom lane
--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general