FAQ
Note: Sent to NetBSD and PostgreSQL mailing lists as I am not sure
exactly where the problem lies.

I am running PostgreSQL 6.5 on a NetBSD system running -current. When
I try to include my user defined type I get the following error.

ERROR: Load of file /usr/pgsql/modules/glaccount.so failed: dlopen (/usr/pgsql/modules/glaccount.so) failed

The file definitely exists and is world readable as the following indicates.

[db@smaug:/usr/db] $ ls -l /usr/pgsql/modules/glaccount.so
-rwxr-xr-x 1 pgsql pgsql 3826 Jul 25 05:04 /usr/pgsql/modules/glaccount.so
[db@smaug:/usr/db] $ file /usr/pgsql/modules/glaccount.so
/usr/pgsql/modules/glaccount.so: ELF 32-bit LSB shared object, Intel 80386, version 1, not stripped

The error message isn't very informative. Is there some way to get more
information on why the load failed?

Thanks for any 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.

Search Discussions

  • Tom Lane at Jul 25, 1999 at 4:08 pm

    "D'Arcy" "J.M." Cain 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
  • Jaromir Dolecek at Jul 25, 1999 at 7:04 pm

    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
  • "D'Arcy" "J.M." Cain at Jul 26, 1999 at 2:43 am
    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.
  • "D'Arcy" "J.M." Cain at Jul 26, 1999 at 2:40 am
    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.
  • Mark Hollomon at Jul 26, 1999 at 1:32 pm

    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
  • Klaus Klein at Jul 25, 1999 at 7:52 pm
    "D'Arcy" == J M <D> writes:
    D'Arcy> ERROR: Load of file /usr/pgsql/modules/glaccount.so
    D'Arcy> failed: dlopen (/usr/pgsql/modules/glaccount.so) failed

    D'Arcy> The error message isn't very informative. Is there some
    D'Arcy> way to get more information on why the load failed?

    For more information you can try to set LD_DEBUG to a non-null value
    in the execution environment - the shared loader should give you a
    hint what's going on; as an alternative, you can add a call to
    dlerror() at the place in question and print the string returned.
    (The code should probably do that anyway, but if it already does and
    dlerror() returned a null pointer that would be a bug in the shared
    loader.)

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppgsql-hackers @
categoriespostgresql
postedJul 25, '99 at 1:06p
activeJul 26, '99 at 1:32p
posts7
users5
websitepostgresql.org...
irc#postgresql

People

Translate

site design / logo © 2022 Grokbase