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)

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

ldd now shows this.

glaccount.so:
-lpq => /usr/pgsql/lib/libpq.so
-lc.12 => /usr/lib/libc.so.12

Actually, do you even need libpq? That's a client-side library; I don't
think it should get linked into shlibs that are intended to be dynlinked
into the server...

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.

08138544 D CurrentMemoryContext

Hmm. On HPUX there is a special linker switch you have to use when the
main program is linked to make the linker "export" the main-program
symbols so that they will be visible to dynlinked libraries. Perhaps
your platform needs something similar.

regards, tom lane

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.

Thus spake Tom Lane

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

glaccount.so:
-lpq => /usr/pgsql/lib/libpq.so
-lc.12 => /usr/lib/libc.so.12

Actually, do you even need libpq? That's a client-side library; I don't
think it should get linked into shlibs that are intended to be dynlinked
into the server...

Yah, I was just trying stuff. As it turns out, PostgreSQL doesn't
recognize NetBSD as an ELF system unless it is a powerpc. That's
probably correct as it is only -current that is ELF, not the release.
If it helps, here is the output of "file /netbsd" which tells you for
sure it is an ELF system.

/netbsd: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped

so;

if [ "`file /netbsd | cut -d' ' -f2`" = "ELF" ]
then elf=yes
fi

Under the netbsd secion of configure_in should do it.

-- 
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.

D'Arcy" "J.M." Cain wrote:

Thus spake Tom Lane

"D'Arcy" "J.M." Cain <darcy@druid.net> writes:

glaccount.so:
-lpq => /usr/pgsql/lib/libpq.so
-lc.12 => /usr/lib/libc.so.12

Actually, do you even need libpq? That's a client-side library; I don't
think it should get linked into shlibs that are intended to be dynlinked
into the server...

Yah, I was just trying stuff. As it turns out, PostgreSQL doesn't
recognize NetBSD as an ELF system unless it is a powerpc. That's
probably correct as it is only -current that is ELF, not the release.

Actually, alpha is ELF from the day one too. mips is ELF from
the 1.3.X release IIRC. Just the i386 & sparc
have been switched to ELF recently. With exception of x68k & pc532,
ELF is accross the board now.

If it helps, here is the output of "file /netbsd" which tells you for
sure it is an ELF system.

/netbsd: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped

so;

if [ "`file /netbsd | cut -d' ' -f2`" = "ELF" ]
then elf=yes
fi

Under the netbsd secion of configure_in should do it.

A bit more sane would be to compile and run this little program on NetBSD:
int main() {
#ifdef __ELF__
return 1;
#else
return 0;
#endif
}

ELFism of userland is independant of kernel (ELF kernel can run
with a.out userland & a.out kernel can run ELF userland), so this
method is probably safer.

--
Jaromir Dolecek <dolecek@ics.muni.cz> http://www.ics.muni.cz/~dolecek/
"The only way how to get rid temptation is to yield to it." -- Oscar Wilde

On Tue, 27 Jul 1999, D'Arcy J.M. Cain wrote:

Yah, I was just trying stuff. As it turns out, PostgreSQL doesn't
recognize NetBSD as an ELF system unless it is a powerpc. That's
probably correct as it is only -current that is ELF, not the release.
If it helps, here is the output of "file /netbsd" which tells you for
sure it is an ELF system.

/netbsd: ELF 32-bit LSB executable, Intel 80386, version 1, statically linked, not stripped

so;

if [ "`file /netbsd | cut -d' ' -f2`" = "ELF" ]
then elf=yes
fi

Under the netbsd secion of configure_in should do it.

The ELFness of the kernel is independant to the ELFness of the
userland - you may want to run a file on some userland binary
instead.

David/absolute

-=- Sue me, screw me, walk right through me -=-

If it helps, here is the output of "file /netbsd" which tells you for
sure it is an ELF system.

/netbsd: ELF 32-bit LSB executable, Intel 80386, version 1, statically linke
d, not stripped

so;

if [ "`file /netbsd | cut -d' ' -f2`" = "ELF" ]
then elf=yes
fi

Under the netbsd secion of configure_in should do it.

It's worth getting this really right during the migration to ELF...

That test doesn't work on pmax systems which have ECOFF-format kernels
(for netbooting) and ELF userland. A `clean' test that asks the kernel
what format(s) it supports would be nice; absent that, testing on
userland binaries as well --say /usr/libexec/ld.elf_so (or maybe
instead?) is safer than relying on the format of the kernel itself.

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)

On Tue, Jul 27, 1999 at 01:24:30PM -0400, D'Arcy J.M. Cain wrote:

recognize NetBSD as an ELF system unless it is a powerpc. That's
probably correct as it is only -current that is ELF, not the release.
If it helps, here is the output of "file /netbsd" which tells you for
sure it is an ELF system.

Please note that NetBSD is already ELF on some platforms, e.g macppc and
pmax. Other platforms are still only aout, e.g. m68k and others. At least
two platforms have changed to ELF since the last NetBSD release (i386
and sparc) and will be ELF when NetBSD 1.5 is released (but not 1.4.1 and
other patch releases for 1.4).

The end result is that 3rd party software should not decide ELF-ness based
on versions or platforms, but try to detect the actual status of the system
on which it installs.

- Erik