Thread: Re: More on shared objects problem

Re: More on shared objects problem

From
Todd Vierling
Date:
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)



Re: More on shared objects problem

From
"D'Arcy" "J.M." Cain
Date:
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.


Re: More on shared objects problem

From
Todd Vierling
Date:
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)



Re: [HACKERS] Re: More on shared objects problem

From
"Mark Hollomon"
Date:
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


Re: [HACKERS] Re: More on shared objects problem

From
Thilo Manske
Date:
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.


Re: [HACKERS] Re: More on shared objects problem

From
Todd Vierling
Date:
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)