Re: More on shared objects problem
От | Todd Vierling |
---|---|
Тема | Re: More on shared objects problem |
Дата | |
Msg-id | Pine.NEB.4.10.9907270900370.1286-100000@server.int.duh.org обсуждение исходный текст |
Ответы |
Re: More on shared objects problem
|
Список | pgsql-hackers |
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)
В списке pgsql-hackers по дате отправления: