From: Peter Much <pmc@citylink.dinoex.sub.org>
To: Palle Girgensohn <girgen@freebsd.org>
Cc: freebsd-questions@freebsd.org
Cc: freebsd-ports@freebsd.org
Cc: freebsd-hackers@freebsd.org
Cc: brett_schwarz@yahoo.com
Cc: pgsql-interfaces@postgresql.org
Subject: Re: FreeBSD 5.3: Sharedlibs using sharedlibs (and Tcl)
Date: Wed, 16 Mar 2005 20:13:03 +0100
Message-ID: <20050316191303.GA87431@gate.oper.dinoex.org> (raw)
In-Reply-To: <012F732A0FD93F1880662177@rambutan.pingpong.net>
References: <20050315170656.GA73993@gate.oper.dinoex.org>
<9C05F10029508113D296723A@rambutan.pingpong.net>
<20050315185224.GA83998@gate.oper.dinoex.org>
<DB9B42B90967A6251F6223D2@palle.girgensohn.se>
<20050316104331.GA56139@gate.oper.dinoex.org>
<012F732A0FD93F1880662177@rambutan.pingpong.net>
On Wed, Mar 16, 2005 at 03:35:16PM +0100, Palle Girgensohn wrote:
!
! --On onsdag, mars 16, 2005 11.43.31 +0100 Peter Much
! <pmc@citylink.dinoex.sub.org> wrote:
!
! >! So, you're saying that pctclsh *can* access, but pgaccess *cannot*?
! >Odd... ! I would expect they'd both use the same lib to connect, no?
! >I'll have to
! >
! >They use the same libraries, yes. But Tcl interpreter seem to need more
! >advice on where to find sub-functions in other libraries. It looks
! >like this:
! >
! >pgtclsh -finds-> libpgtcl.so -finds-> libpq.so -finds-> libkrb5.so
! >pgaccess -loads-> libpgtcl.so -finds-> libpq.so -fails-> libkrb5.so
!
! Uh, OK. I'm not qualified enough with linkers to answer this, I'm afraid.
! Did you try the pgsql-interfaces mailing list?
Oh well, same with me. I sent a copy of one of my reports to that
list, yes. But only got feedback that it will be evaluated by
moderator, as I am not signed on that list.
I'm actually no professional psql user - the database is just a small
part of my installation, mainly logging the lowlevel error counts
from my exabyte drives and providing reports about tape wearout.
And the kerberos is just there for fun, as a reference installation.
Nevertheless, I would think this is not a matter for the postgres
community. Because this would happen the same way with any other
application that provides Tcl support and kerberos support (or maybe
also with other components of the system, if they are used from Tcl).
So it seems either a Tcl problem or a linker/loader problem. Which,
I cannot say - maybe both.
! >And then I found that it is enough to place into libpq.so the explicit
! >references to libkrb5 and the other kerberos libs. That is what the
! >"readelf -a" output in my other mail shows.
!
! sounds like a better solution, yes... Shouldn't they always be there?
! Sounds like a bug to me?
Thats the question.
I just did a little more investigation (like reading manpages)
and found out _WHY_ it does work for pgtclsh but not for pgaccess.
There is a command "ldd" that shows nested library dependencies
for any program.
For pgtclsh it shows all the kerberos libs:
bash-3.00# ldd /usr/local/bin/pgtclsh
/usr/local/bin/pgtclsh:
libpgtcl.so.2 => /usr/local/lib/libpgtcl.so.2 (0x28075000)
libpq.so.3 => /usr/local/lib/libpq.so.3 (0x2807d000)
libtcl84.so.1 => /usr/local/lib/libtcl84.so.1 (0x28097000)
libm.so.3 => /lib/libm.so.3 (0x28135000)
libkrb5.so.7 => /usr/lib/libkrb5.so.7 (0x2814f000)
libasn1.so.7 => /usr/lib/libasn1.so.7 (0x28186000)
libcrypto.so.3 => /lib/libcrypto.so.3 (0x281a6000)
libroken.so.7 => /usr/lib/libroken.so.7 (0x2829b000)
libcrypt.so.2 => /lib/libcrypt.so.2 (0x282a9000)
libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x282c1000)
libz.so.2 => /lib/libz.so.2 (0x282c3000)
libreadline.so.5 => /lib/libreadline.so.5 (0x282d3000)
libutil.so.4 => /lib/libutil.so.4 (0x282ff000)
libc.so.5 => /lib/libc.so.5 (0x2830b000)
libintl.so.6 => /usr/local/lib/libintl.so.6 (0x283e4000)
libssl.so.3 => /usr/lib/libssl.so.3 (0x283ed000)
libncurses.so.5 => /lib/libncurses.so.5 (0x2841b000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2845a000)
But for libpgtcl.so (this is the first elf binary that pgaccess gets
to see) it does not show these kerberos libraries (I use the old
libpq.so here, not the one that I have modified):
bash-3.00# ldd /usr/local/lib/libpgtcl.so
/usr/local/lib/libpgtcl.so:
libpq.so.3 => /usr/local/lib/libpq.so.3 (0x2815a000)
libtcl84.so.1 => /usr/local/lib/libtcl84.so.1 (0x28174000)
libm.so.3 => /lib/libm.so.3 (0x28212000)
libintl.so.6 => /usr/local/lib/libintl.so.6 (0x2822c000)
libssl.so.3 => /usr/lib/libssl.so.3 (0x28235000)
libcrypto.so.3 => /lib/libcrypto.so.3 (0x28263000)
libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x28358000)
Then the explanation became simple: these kerberos libraries get
just LITERALLY LISTED WITHIN THE pgtclsh BINARY! And this is an
impossible method for a Tcl script.
bash-3.00# readelf -d /usr/local/bin/pgtclsh | grep krb5
0x00000001 (NEEDED) Shared library: [libkrb5.so.7]
So now we have a full explanation for the behaviour, but not really
a solution.
Instead, this looks like a fundamental question about how to load
nested elf sharedlibs from interpreter languages.
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: pmc@citylink.dinoex.sub.org, girgen@freebsd.org, freebsd-questions@freebsd.org, freebsd-ports@freebsd.org, freebsd-hackers@freebsd.org, brett_schwarz@yahoo.com
Subject: Re: FreeBSD 5.3: Sharedlibs using sharedlibs (and Tcl)
In-Reply-To: <20050316191303.GA87431@gate.oper.dinoex.org>
* 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