James Thompson <jamest@math.ksu.edu> writes:
> Now if I enter tcl and type
> tcl> load /usr/local/lib/libobe.so
> I get an error about an unresolved symbol no_trans_auto (or something like
> that, I'm not at home to check the extact symbol name) no_trans_auto is
> part of the ecpg package which is in /usr/local/postgresql
> I have my LD_LIBRARY_PATH = /usr/local/postgresql/lib/
> an ldd of libobe.so reports statically linked (and if the execute bit
> isn't set it complains, anyone know why)
> 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.
I don't think this has anything directly to do with autoconfig, swig,
or any of that stuff; rather the problem is that cross-references from
one shared library to another are not handled very well on many Unix
systems.
If shlib A refers to symbols in shlib B then the dynamic linker has to
be told that shlib B must be loaded first, and it has to be able to find
shlib B. There are various ways of doing this, including embedding an
absolute path to B in A (works great as long as B was installed in its
final location *before* you linked A), putting only B's name in A and
using a search path or external table to find where B actually lives,
etc etc. I don't know how your particular system does it.
In any case you have to be sure that shlib B is mentioned on the command
line that links shlib A, or the required info won't be put into A.
The problem doesn't usually show up when you make an executable that
binds in shlibs at link time, because all the required shlibs get listed
in the executable program. The hard case is dynamically loading a new
shlib as tcl's "load" command tries to do; if the reference info in the
incoming shlib isn't 100% right, it won't work.
libtool 1.2 does not handle this sort of thing very well, I believe.
1.3 is supposed to have proper support for cross-shlib references;
you might want to try the current alpha version to see if it is stable
enough for you.
If you aren't able to get around the problem, making a custom tcl
executable with all the necessary libs included at link time will
probably work.
regards, tom lane