Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 15 Mar 2005 18:06:56 +0100
From:      Peter Much <pmc@citylink.dinoex.sub.org>
To:        freebsd-questions@freebsd.org
Cc:        brett_schwarz@yahoo.com
Subject:   FreeBSD 5.3: Sharedlibs using sharedlibs (and Tcl)
Message-ID:  <20050315170656.GA73993@gate.oper.dinoex.org>

next in thread | raw e-mail | index | archive | help
Hi all,

my question is, 
  which references to other sharedlibs need to be in a shared
library?

When installing postgresql database system and the Tcl interface tool 
"pgaccess", I noticed that the kerberos support did not work.

I installed postgresql 7.4.5 from the ports colletion as of RELEASE
5.3. This is not the newest, so I did not create a bugreport, but 
instead figured out the problem (and a solution) by myself (with
some support from the pgaccess user community).

But now I would like to *understand* what was going wrong and why 
I could fix it the way I did.

I describe the fabric:
1. postgresql brings a library "libpq.so.3" into /usr/local/lib. This
   library contains all the code to access the database server.
   If we use kerberos, then this library will call functions from
   the bunch of kerberos libraries (libkrb5, libasn1, etc etc)
   in /usr/lib.
2. postgresql also brings another, optional library "libpgtcl.so.2"
   into /usr/local/lib. This library contains special function for
   accessing the database server from Tcl. 
   This library calls the functions in libpq.so.3.
3. pgaccess is a Tcl script. It wants to load libpgtcl.so. It finds
   and loads libpgtcl.so, it finds and loads the necessary functions
   from libpq.so, and then, if we have kerberos compiled in, it 
   recognizes one of the needed kerberos functions, and complains
   that it cannot find this function referenced from libpq.so. So the 
   load of libpgtcl.so fails.

As far as I see, this problem does not arise with binaries. All
binary progams using libpq.so do support kerberos, and it works. 

Then I noticed that sharedlibs contain a section where other needed
sharedlibs can be explicitely mentioned. And I noticed that
libpgtcl.so contains such a mentioning of libpq.so - so this is 
found by Tcl. 
But libqp.so does not contain an explicit mentioning of the kerberos
libraries.
So I tried around with the linker command until I practiced such
an explicit mentioning into libpq.so.
And then step 3 from above did succeed!

I conclude:
Since this is now a matter of how sharedlibs are built on the system,
this does not only concern kerberos and postgresql, but concerns any
component which shall be called from Tcl.

I have now two versions of my libpq.so - both contain the same code,
but one will support kerberos from Tcl, and the other (the one that
was built in the standard way) will not.
The only difference between both shows up in the output of "readelf
-a" as follows:

The standard build that does not work:
-------------------------------------------------------
[...]
Dynamic segment at offset 0x19774 contains 21 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED) Shared library: [libintl.so.6]
 0x00000001 (NEEDED) Shared library: [libssl.so.3]
 0x00000001 (NEEDED) Shared library: [libcrypto.so.3]
 0x0000000e (SONAME) Library soname: [libpq.so.3]
 0x0000000f (RPATH) Library rpath: [/usr/local/lib]
[...]

My modified build that does work:
-------------------------------------------------------
[...]
Dynamic segment at offset 0x19774 contains 26 entries:
  Tag        Type                         Name/Value
 0x00000001 (NEEDED) Shared library: [libintl.so.6]
 0x00000001 (NEEDED) Shared library: [libssl.so.3]
 0x00000001 (NEEDED) Shared library: [libcrypto.so.3]
 0x00000001 (NEEDED) Shared library: [libkrb5.so.7]
 0x00000001 (NEEDED) Shared library: [libasn1.so.7]
 0x00000001 (NEEDED) Shared library: [libroken.so.7]
 0x00000001 (NEEDED) Shared library: [libcrypt.so.2]
 0x00000001 (NEEDED) Shared library: [libcom_err.so.2]
 0x0000000e (SONAME) Library soname: [libpq.so.3]
 0x0000000f (RPATH) Library rpath: [/usr/local/lib]
[...]

So, my question now is: where is the conceptional error which led 
to the software not working at first?
In Tcl? In the linker? In the system loader? In the build environment 
(port)? In the postgresql makefiles? In the FreeBSD sharedlib 
management? In kerberos? Or somewhere else?

And this seems complex enough to me so I do not even know how
to search if it might be a known bug that has already been fixed
in the meantime...

PMc



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050315170656.GA73993>