Обсуждение: More on shared objects problem
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 $@ $<
ldd now shows this.
glaccount.so: -lpq => /usr/pgsql/lib/libpq.so -lc.12 => /usr/lib/libc.so.12
I then went into the PostgreSQL code and added a dlerror() call to the
error message after dlopen(). I still get an error but now I get a little
more information.
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
So it looks like everything should be working but it doesn't. Is this
possibly a case of bogus error message or am I misunderstanding it? Is
ELF fully baked or do I need to revert to a pre-ELF system?
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. Is nm like ldconfig and
not needed any more on ELF systems or is there just a problem with
the current sources?
--
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 <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 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;
#elsereturn 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 theuserland - you may want to run a file on some userland
binaryinstead.
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, 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