Thread: shared libs(tcl/swig/ecpg/postgresql)
Sorry for the cross post but I'm not really sure where to look for this problem. I'm writing a library in C that uses ecpg to embed sql commands into the c source which accesses a postgresql. I'm trying to use tcl/tk for the front end. With swig tying the C to the tcl/tk. I've made my interface file (obe.i) and swig'd it with -tcl8. The wrapper code compiles and links without errors as far as I can tell. And the installed lib resides at /usr/local/lib. 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'm sure this is a stupid error on my part, this is my first experience with using automake, autoconfig, libtool (shared lib creation as well), and swig and I think I may have finally popped a cranial fuse. I've spent two days with this reading everything I find on-line and I'm getting nowhere. Any help would be greatly appreciated. Additional info: RH5.1 with RPMs of autoconf, automake, libtool, gcc Latest TCL/TK downloaded and installed from source last week Latest swig downloaded from source and installed two days agon ecpg included with postgresql 6.4.2 downloaded and installed from source ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
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
On Tue, Feb 02, 1999 at 01:24:40PM -0600, James Thompson wrote: > 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 no_auto_trans is an integer defined in libecpg.so taht's right. It is included as external reference into the *.c files by ecpg via ecpglib.h. So I guess you have your *.pgc files correctly in the lib but the reference to libecpg isn't fulfilled. > 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. Michael -- Michael Meskes | Go SF 49ers! Th.-Heuss-Str. 61, D-41812 Erkelenz | Go Rhein Fire! Tel.: (+49) 2431/72651 | Use Debian GNU/Linux! Email: Michael.Meskes@gmx.net | Use PostgreSQL!
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
On Wed, 3 Feb 1999, Tom Lane wrote: > Michael Meskes <Michael_Meskes@usa.net> writes: > > that some systems' dynamic linkers are too stupid to follow the > second-level reference and pull in libcrypt as part of the dynamic load. > This is what I'm seeing. I played around with my Makefile.am file for just a few, um, hours last night and couldn't figure out a way around it. But I a complete newbie to the automake/config/shared lib setup so I spent more time screwing things up than fixing them :-( > 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. > I'd like to try this with my functions but I'm stumped on how to do this via the automake/libtool design. I'm not using libpgtcl.so for my tcl access to postgres. I'm using C and ecpg to create the functions I need. I don't want people doing direct access to the database. I want them to use my functions so that several databases can be supported without changing the UI and vice versa. I'm using SWIG to create tcl wrappers for the functions with an eye toward easy guile/perl support (via SWIG) in the future. > > 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. > I can't find libtool 1.3. I tried the oficial home page found via google and their alpha ftp link didn't have 1.3 software. > > 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 :-( > I would have sworn that adding this to the _LDFLAGS would have done this but it just doesn't work. Man this is frustrating, I know the library calls work when linked to a C test program with the TCL wrapper code compiled against the library. I assume that the library should now work linked to C or loaded into TCL but the TCL load fails. I'll look at how libpgtcl links into postgresql and tcl tonight, but if anyone has a example of forcing shared libs to link together with awareness of each other using automake/libtool I'd be eternally gratefull if they would e-mail me a copy. Thank you. ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-< James Thompson 138 Cardwell Hall Manhattan, Ks 66506 785-532-0561 Kansas State University Department of Mathematics ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
James Thompson <jamest@math.ksu.edu> writes:
>> 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.
> I can't find libtool 1.3.
That's 'cause it doesn't exist yet. You can get libtool's current
development sources from the GNU CVS server, but I wouldn't vouch for
them being stable...
regards, tom lane