Subject: Re: More on shared objects problem
To: D'Arcy J.M. Cain <darcy@druid.net>
From: Todd Vierling <tv@pobox.com>
List: current-users
Date: 07/27/1999 09:04:58
On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote:
: Many thanks to everyone who helped so far especially Todd Vierling for
: the RTFF. I think I am closer but I still have a problem. Here is the
: rule in my makefile now.
:
: .o.so:
: ld -shared -L${PGDIR}/lib --export-dynamic -rpath ${PGDIR}/lib \
: -lpq -lc -o $@ $<
--export-dynamic is only needed for _executables_. It is implied for shared
objects.
BTW, for platform compatibility, may I suggest using -R instead of -rpath...
that works on all NetBSD, a.out and ELF, linkers (and even some non-NetBSD
ones :).
: ERROR: Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed (/usr/pgsql/modules/glaccount.so: Undefined symbol "CurrentMemoryContext" (reloc type = 6, symnum = 6))
:
: CurrentMemoryContext is defined in the postmaster (I checked with nm) which
: is the program doing the dlopen. Here is the relevant line from nm.
...and you don't have --export-dynamic on your _executable's_ link line.
When linking the executable whose symbols will be used by a shared object,
use:
cc -Wl,-E ...
(which is equivalent, from the cc side).
: Hmm. I just noticed that nm is an old binary and that it doesn't build
: from current sources due to a missing bfd.h.
You need the sources of src/gnu/lib/libbfd and
src/gnu/dist/{opcodes,bfd,libiberty} in order to build any libbfd using
program. This is because there are a lot of internal bfd headers used by
these programs. However, there is nothing wrong with your nm.
--
-- Todd Vierling (tv@pobox.com)