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>