linking problems with heimdal in base (ports version works)

Palle Girgensohn girgen at pingpong.net
Sun Oct 30 16:03:57 PST 2005



--On måndag, oktober 17, 2005 18.18.56 -0400 Brian Fundakowski Feldman 
<green at freebsd.org> wrote:

> On Sun, Oct 16, 2005 at 09:04:58PM +0400, Igor Pokrovsky wrote:
>> On Sun, Oct 16, 2005 at 06:35:51PM +0200, Michael Nottebrock wrote:
>> > On Sunday, 16. October 2005 09:06, Igor Pokrovsky wrote:
>> > > On Fri, Oct 14, 2005 at 09:49:51PM +0200, Michael Nottebrock wrote:
>> > > > On Friday, 14. October 2005 21:11, Igor Pokrovsky wrote:
>> > > > > > Still, isn't it strange that the kerberos libs don't have any
>> > > > > > dependencies registered? A quick check shows that they are
>> > > > > > almost the only libs in /usr/lib that have zero output from
>> > > > > > ldd.
>> > > > >
>> > > > > Probably they are statically linked.
>> > > >
>> > > > No, static libraries don't come with an .so extension. :-)
>> > >
>> > > No, you missed my point. I mean that kerberos libs are dynamic but
>> > > linked against other libraries statically.
>> >
>> > If they were, there would be no problem in the first place.
>>
>> Sorry, it seems I missed a part of the thread.
>
> Either the ports that use libkrb5 must know its dependencies or they
> must be encoded in the shared library's header as dependencies.  I vote
> for #1 because it's too late for #2.  See previous post about how to
> solve this.

Hi,

I'm back on this subject.

Just to make things clear: there are no static linking in heimdal. The 
dependencies between the different libs are just not registered in the base 
userland dist, but they are in the heimdal port.

The Postgresql port does make use of krb5-config --libs. Problem is, they 
don't get into libpq.so, so all dependant ports must also know that they 
need kerberos if postgresql was linked with it. the pg_config utility has 
no way of helping out here. My view is that the base heimdal installation 
is buggy, it should register dependencies between the shared libs.

Here's how libpq.so is linked:

palle:libpq$ cc -O -pipe -march=athlon-xp -Wall -Wmissing-prototypes 
-Wpointer-arith -Wdeclaration-after-statement -Wold-style-definition 
-Wendif-labels -fno-strict-aliasing  -fPIC -DPIC -shared 
-Wl,-x,-soname,libpq.so.4  fe-auth.o fe-connect.o fe-exec.o fe-misc.o 
fe-print.o fe-lobj.o fe-protocol2.o fe-protocol3.o pqexpbuffer.o pqsignal.o 
fe-secure.o md5.o ip.o wchar.o encnames.o noblock.o pgstrcasecmp.o thread.o 
-L../../../src/port -L/usr/lib -L/usr/local/lib -lssl -lcrypto -lkrb5 
-lcrypto -lcrypt -lroken -lasn1 -lcom_err -Wl,-R/usr/local/lib -o libpq.so.4
palle:libpq$ ldd libpq.so
libpq.so:
        libssl.so.3 => /usr/lib/libssl.so.3 (0x28190000)
        libcrypto.so.3 => /lib/libcrypto.so.3 (0x281c3000)
        libkrb5.so.7 => /usr/lib/libkrb5.so.7 (0x282d4000)
        libcrypt.so.2 => /lib/libcrypt.so.2 (0x28312000)
        libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x2832b000)
palle:libpq$

as you can see, the libasn1 is missing, and that fact makes other stuff, 
like libpqxx, fail to build, since it misses symbols:

configure:20828: checking for main in -lpq
configure:20852: cc -o conftest -O -pipe -march=athlon-xp 
-I/usr/local/include  -L/usr/local/lib conftest.c -lpq -L/usr/local/lib  >&5
/usr/lib/libkrb5.so.7: undefined reference to `length_PA_ENC_TS_ENC'
/usr/lib/libkrb5.so.7: undefined reference to `length_KDC_REQ_BODY'
/usr/lib/libkrb5.so.7: undefined reference to `free_Principal'
/usr/lib/libkrb5.so.7: undefined reference to `bswap16'
/usr/lib/libkrb5.so.7: undefined reference to `length_EncKrbCredPart'
/usr/lib/libkrb5.so.7: undefined reference to `copy_Realm'
/usr/lib/libkrb5.so.7: undefined reference to `strlwr'
/usr/lib/libkrb5.so.7: undefined reference to `length_TGS_REQ'
/usr/lib/libkrb5.so.7: undefined reference to `decode_TGS_REP'
/usr/lib/libkrb5.so.7: undefined reference to `copy_PrincipalName'


Now, you might argue that every single port must know that it shall use 
kerberos, and add relevant libs to its linker lines, but why all that 
effort? The security/heimdal port has dependencies registered, so that 
works fine to link. (The base heimdal must be removed so it won't be picked 
up by the linker)

Is there any way to "force" dependencies into a lib? If so, I could 
register -lasn1 in libpq.som and everything would be dandy.

If you need to fresh your memory up, here's the original question:

> I'm having some difficulties using postgresql version 8.0.x with heimdal
> installed from /usr/src (i.e. the base system). This is on FreeBSD-5.x.
> When using the port of heimdal, from /usr/ports/security/heimdal, it
> works.
>
> The port install into /usr/local, whereas the base system is in /usr.
> Here's the difference between the heimdal port and the heimdal
> distributed in the base:
>
> $ ldd /usr/local/lib/libkrb5.so
> /usr/local/lib/libkrb5.so:
>         libcrypto.so.3 => /lib/libcrypto.so.3 (0x281b3000)
>         libasn1.so.6 => /usr/local/lib/libasn1.so.6 (0x282c4000)
>         libroken.so.16 => /usr/local/lib/libroken.so.16 (0x282ea000)
>         libcrypt.so.2 => /lib/libcrypt.so.2 (0x282f8000)
>         libcom_err.so.2 => /usr/lib/libcom_err.so.2 (0x28311000)
> $ ldd /usr/lib/libkrb5.so
> /usr/lib/libkrb5.so:
> $
>
> Same goes for the other heimdal libs, libasn1.so and libcom_err.so.
>
> I don't know enough about linking details, but shouldn't the
> /usr/lib/libkrb5.so lib also contain info about libraries it depends on?
...


Regards,
Palle



More information about the freebsd-stable mailing list