Michael Meskes <Michael_Meskes@usa.net> writes:
>> If I attempt to load a library that ecpg depends on I get unresoved
>> symbols at each library. I ended up with tcl not being able to resolve
>> symbols in libcrypt.so I simple test file written in C seems to access
>> the library fine.
> libcrypt should only depend on libc.so.6 aka glibc2 and ld-linux.so.2.
>
> Since I don't know tcl I'm at a loss here.
It's not tcl that's depending on libcrypt --- it's libpq, which tcl is
attempting to load dynamically.
On some machines crypt() is not part of libc but is in a separate shlib
libcrypt.so. It seems when you have
tcl loading libpgtcl.so (via a dynamic load operation)
libpgtcl.so depending on libpq.so
libpq.so depending on libcrypt.so
that some systems' dynamic linkers are too stupid to follow the
second-level reference and pull in libcrypt as part of the dynamic load.
The only workaround I know of is to mark libpgtcl.so as also depending
on libcrypt.so, even though it has no direct reference to libcrypt.
Then everything that has to be linked is visible at the top level so
these (broken) linkers will succeed. This really bites, because the
implication is that every shared lib has to be fully cognizant of the
dependencies of the shared libs that it calls, all the way down to the
bottom of the call tree.
GNU libtool 1.3 is supposed to be able to hide this sort of brain-damage
(by tracing the dependencies for you, I suppose). As soon as it's out
of beta I plan to switch Postgres' various shared libraries over to
being built with libtool. Right now we're kind of limping along with
hand-hacked shared library build rules.
Anyway, bottom line is to try adding -lcrypt to the command that creates
libpgtcl.so. Probably we should just put that into the makefiles for
libpgtcl and libpq++ and all the rest of the callers of libpq :-(
regards, tom lane
