Building agains dynamic libptread in Debian Stable

[Greg Hudson]

On 07/09/2012 01:34 PM, Alejandro Perez Mendez wrote:
>> Isn't this just a matter of mech_eap.so needing libpthread as a
>> dependency?
> 
> Well yes. But it also means that I have to change how krb5kdc is built
> (and maybe the kinit), so it includes pthread into the linking
> libraries, right?

No, you shouldn't have to do this if mech_eap.so has proper dependencies.

> Then that should be it. I just checked it with ldd, and libpthread were there.

For reference, "objdump --private-headers filename | grep NEEDED" will
let you see the direct dependencies of a library or executable.

> Something similar as what it is done in
> tests/gss-threads, where $(THREAD_LINKOPTS) are included as linking
> options. Otherwise, the KDC and kinit won't be able to provide the
> functions requested by mech_eap.so.

Although it is possible for a dynamically loaded object to resolve
symbols from the current linker map (when not loaded with RTLD_GROUP, at
least), it is much better if all symbols used by the object can be
resolved via its dependencies.  Certainly, we don't consider it
appropriate to link in a bunch of libraries just in case a loadable
module happens to use one of them without properly depending on it.

> I'm talking of including -lpthread when linking programs. That is not
> currently done in my system, using Kerberos 1.10.2. At least for the
> krb5kdc, the gss-client and the gss-server programs.

My mistake; we use PTHREAD_CFLAGS to link programs on some platforms,
but not on Linux.