pg.ddx.io  pgsql-interfaces@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Michael Meskes <Michael_Meskes@usa.net>
Cc: pgsql-interfaces@postgreSQL.org
Subject: Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)
Date: Wed, 03 Feb 1999 15:24:04 -0500
Message-ID: <5746.918073444@sss.pgh.pa.us> (raw)
In-Reply-To: <19990203085445.A2420@gmx.net>

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



view thread (6+ messages)  latest in thread

Message-ID: <5746.918073444@sss.pgh.pa.us>
Permalink:  ../5746.918073444@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/5746.918073444@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-interfaces@postgresql.org
  Cc: tgl@sss.pgh.pa.us, Michael_Meskes@usa.net
  Subject: Re: [INTERFACES] shared libs(tcl/swig/ecpg/postgresql)
  In-Reply-To: <5746.918073444@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox