Horton

Thread

  1. Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed

    Tom Lane <tgl@sss.pgh.pa.us> — 1999-07-25T16:06:46Z

    "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> ERROR:  Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed

> The error message isn't very informative.

Dynamic loaders tend to be pretty horrid about that :-(.  My bet is
a failure to resolve an external reference to another shared library.
Try using "ldd" (or local equivalent) on the shlib to find out what
other shlibs it depends on.  Be suspicious if ldd fails to show all the
dependencies you expect (eg, practically anything will depend on libc);
that probably means the linker failed to locate the other shlib when
linking this one.  Next make sure all those other shlibs are in the
right places, and are known to the system if your system keeps a table
of shlibs.  Then start checking *their* dependencies...

			regards, tom lane

  2. Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed

    Jaromir Dolecek <dolecek@ics.muni.cz> — 1999-07-25T19:02:00Z

    Tom Lane wrote:
> "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> > ERROR:  Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed
> 
> > The error message isn't very informative.
> 
> Dynamic loaders tend to be pretty horrid about that :-(.  My bet is
> a failure to resolve an external reference to another shared library.
> Try using "ldd" (or local equivalent) on the shlib to find out what
> other shlibs it depends on.  Be suspicious if ldd fails to show all the
> dependencies you expect (eg, practically anything will depend on libc);
> that probably means the linker failed to locate the other shlib when
> linking this one.  Next make sure all those other shlibs are in the
> right places, and are known to the system if your system keeps a table
> of shlibs.  Then start checking *their* dependencies...

Further lossage - ELF vs. a.out: when calling() dlsym(3), a.out
needs the symbols prepended with underscore, but ELF doesn't. Got bitten
by this bit when helping garbled with ClanLib ...
You might check the source if a.out systems are handled right ....

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

  3. Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed

    D'Arcy Cain <darcy@druid.net> — 1999-07-26T02:39:47Z

    Thus spake Tom Lane
> "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> > ERROR:  Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed
> 
> Dynamic loaders tend to be pretty horrid about that :-(.  My bet is
> a failure to resolve an external reference to another shared library.
> Try using "ldd" (or local equivalent) on the shlib to find out what
> other shlibs it depends on.  Be suspicious if ldd fails to show all the
> dependencies you expect (eg, practically anything will depend on libc);
> that probably means the linker failed to locate the other shlib when
> linking this one.  Next make sure all those other shlibs are in the
> right places, and are known to the system if your system keeps a table
> of shlibs.  Then start checking *their* dependencies...

OK, so what do I do to fix it?  Do I need more options to my link command?
My link rule is now this.

.o.so:
    ld -Bshareable -L ${PGDIR}/lib -lpq -lc -o $@ $<

And here is what ldd shows.

[darcy@smaug:/usr/pgsql/modules] $ ldd glaccount.so
glaccount.so:
         -lpq => not found
         -lc.12 => /usr/lib/libc.so.12

The file libpq.so exists in the directory ${PGDIR}/lib and I still get the
same problem.  I tried nm and I get the following external symbols.

[darcy@smaug:/usr/pgsql/modules] $ nm -Cn glaccount.so
         U CurrentMemoryContext
         U MemoryContextAlloc
         U _ctype_
         U elog
         U sprintf
         U strtol
[... internal symbols ...]

I assume those first two are in the libpq library that wasn't found.

And I just now had a panic while investigating why ldconfig is not being built.
Can I assume that ldconfig is not used in an ELF system?  Did faking it
out and trying to build it cause the panic?  The panic was;

panic: lockmgr: pid %d, not exclusive lock holder %d unlocking

I have crash files if anyone is interested.

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

  4. Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed

    D'Arcy Cain <darcy@druid.net> — 1999-07-26T02:43:20Z

    Thus spake Jaromir Dolecek
> Further lossage - ELF vs. a.out: when calling() dlsym(3), a.out
> needs the symbols prepended with underscore, but ELF doesn't. Got bitten
> by this bit when helping garbled with ClanLib ...
> You might check the source if a.out systems are handled right ....

I am running a pure ELF system - or at least I believe I am.  I installed
the latest i386 snapshot from ftp.vex.net then built a new kernel and
then built the world.  The snapshot appeared to be an ELF system so I
assume that the world built on it will be ELF.

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

  5. Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed

    Mark Hollomon <mhh@nortelnetworks.com> — 1999-07-26T13:33:25Z

    D'Arcy J.M. Cain wrote:
> 
> Thus spake Tom Lane
> > "D'Arcy" "J.M." Cain <darcy@druid.net> writes:
> > > ERROR:  Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed
> >
> > Dynamic loaders tend to be pretty horrid about that :-(.  My bet is
> > a failure to resolve an external reference to another shared library.
> > Try using "ldd" (or local equivalent) on the shlib to find out what
> > other shlibs it depends on.  Be suspicious if ldd fails to show all the
> > dependencies you expect (eg, practically anything will depend on libc);
> > that probably means the linker failed to locate the other shlib when
> > linking this one.  Next make sure all those other shlibs are in the
> > right places, and are known to the system if your system keeps a table
> > of shlibs.  Then start checking *their* dependencies...
> 
> OK, so what do I do to fix it?  Do I need more options to my link command?
> My link rule is now this.
> 
> .o.so:
>     ld -Bshareable -L ${PGDIR}/lib -lpq -lc -o $@ $<
> 
> And here is what ldd shows.
> 
> [darcy@smaug:/usr/pgsql/modules] $ ldd glaccount.so
> glaccount.so:
>          -lpq => not found
>          -lc.12 => /usr/lib/libc.so.12

while developing plperl on a linux/ELF system i saw the same thing.
I solved the problem by replacing backend/port/dynloader/linux.[ch] with
copies of the sunos files in the same directories.

postgres uses dl_open and firends on all linux system, even though
dlopen
is directly support on linux/ELF. This seems to be wrong. I think a
configure
test is needed to decide between dlopen (sunos style) and dl_open (or
whatever
it is).
-- 

Mark Hollomon
mhh@nortelnetworks.com
ESN 451-9008 (302)454-9008