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)