Thread: Re: More on shared objects problem
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)
Thus spake Todd Vierling
> On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote:
> : 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.
So I have been told. Removing it didn't help though.
> 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 :).
OK, I did that.
> ...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 ...
Hmm. OK, I'll try to get that into the PostgreSQL code. Is that flag
benign on a non-ELF system or do I have to test for ELF before adding
the flag?
> 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.
I just realized that I have not been supping gnu files. Didn't someone
say here that src/gnu was now included in /src? I supped the current
gnu down and will rebuild the world but I will try the -E first.
Bingo! That was it. OK, I'll see that the change gets back into PostgreSQL.
Hmmm. Looking at the code I see that it does expect to add that flag if
it is on an ELF system. I guess configure needs to be tweaked. I'll
copy (and set followups to) the PostgreSQL list to start discussions
there on that.
So how do we determine that a system is elf? I don't see it in uname. Do
we just run file(1) on the kernel and see if the string "ELF" shows up?
Many thanks for everyone's help.
--
D'Arcy J.M. Cain <darcy@{druid|vex}.net> | Democracy is three wolves
http://www.druid.net/darcy/ | and a sheep voting on
+1 416 424 2871 (DoD#0082) (eNTP) | what's for dinner.
On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote:
(Note that pgsql-hackers is not in my To: header, as I'm not on the list and
cannot post.)
: So how do we determine that a system is elf? I don't see it in uname. Do
: we just run file(1) on the kernel and see if the string "ELF" shows up?
On NetBSD, the following will do it. This may even be platform independednt
if "grep -q" is replaced by "grep >/dev/null 2>&1".
if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then ... a.out action ...
else ... ELF action ...
fi
--
-- Todd Vierling (tv@pobox.com)
D'Arcy J.M. Cain wrote: > > So how do we determine that a system is elf? I don't see it in uname. Do > we just run file(1) on the kernel and see if the string "ELF" shows up? The test I use is to compile a program that opens its own executable and checks for the magic number. \127ELF as I remember. -- Mark Hollomon mhh@nortelnetworks.com ESN 451-9008 (302)454-9008
On Tue, Jul 27, 1999 at 02:35:13PM -0400, Mark Hollomon wrote:
> D'Arcy J.M. Cain wrote:
> > So how do we determine that a system is elf? I don't see it in uname. Do
> > we just run file(1) on the kernel and see if the string "ELF" shows up?
>
> The test I use is to compile a program that opens its own executable
> and checks for the magic number.
Or this:
if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then # ELF
else # a.out
fi
This is not my idea, it's from the patches for apache in the package tree.
--
Dies ist Thilos Unix Signature! Viel Spass damit.
On Tue, 27 Jul 1999, Thilo Manske wrote:
: if echo __ELF__ | ${CC} -E - | grep -q __ELF__; then
: # ELF
: else
: # a.out
: fi
:
: This is not my idea, it's from the patches for apache in the package tree.
It's actually backwards. If the "grep -q" returns true, it's an a.out
system (since cpp did *not* replace __ELF__ with 1).
--
-- Todd Vierling (tv@pobox.com)