FreeBSD 5.3: Sharedlibs using sharedlibs (and Tcl)

[Palle Girgensohn]

Hi Peter,

There is (and was in 5.3 release) a knob to build postgresql with Kerberos. 
WITH_HEIMDAL_KRB5=YES. Did you try that when building PostgreSQL? It would 
probably do the same thing as you managed by trying around with the linker 
command. Setting this knob to yes will add --with-krb5=/usr to the 
configure arguments, and this will trigger stuff in postgresql makefiles 
and possibly also additional code.

I think this is what went wrong; the postgresql source has a configure 
option for building and linking with Kerberos, this option is reflected in 
the port, but it was not used in this case.

Best regards,
Palle



--On tisdag, mars 15, 2005 18.06.56 +0100 Peter Much 
<pmc at citylink.dinoex.sub.org> wrote:

> 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