Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql) - Mailing list pgsql-interfaces
From | James Thompson |
---|---|
Subject | Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql) |
Date | |
Msg-id | Pine.GSO.4.05.9902031432060.20772-100000@noether.math.ksu.edu Whole thread Raw |
In response to | Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql) (Tom Lane <tgl@sss.pgh.pa.us>) |
Responses |
Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)
|
List | pgsql-interfaces |
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 ->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<
pgsql-interfaces by date: