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

D'Arcy J.M. Cain wrote:
>
> Thus spake Tom Lane
> > "D'Arcy" "J.M." Cain <darcy(at)druid(dot)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(at)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(at)nortelnetworks(dot)com
ESN 451-9008 (302)454-9008