Thread: Problem with dlopen and PostgreSQL - load of file failed
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.
"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
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 <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 loadfailed? 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.)
Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed
From
"D'Arcy" "J.M." Cain
Date:
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.
Re: [HACKERS] Problem with dlopen and PostgreSQL - load of file failed
From
"D'Arcy" "J.M." Cain
Date:
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 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