Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)

From: James Thompson <jamest(at)math(dot)ksu(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Michael Meskes <Michael_Meskes(at)usa(dot)net>, pgsql-interfaces(at)postgreSQL(dot)org
Subject: Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)
Date: 1999-02-03 21:17:30
Message-ID: Pine.GSO.4.05.9902031432060.20772-100000@noether.math.ksu.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

On Wed, 3 Feb 1999, Tom Lane wrote:

> Michael Meskes <Michael_Meskes(at)usa(dot)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
->->->->->->->->->->->->->->->->->->---<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<-<

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Andreas Kaschke 1999-02-03 21:35:25 subscribe
Previous Message Tom Lane 1999-02-03 20:24:04 Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)