[OpenAFS] Re: 1.6.2 compilation notes, Sol10

[Russ Allbery]

Andrew Deason <adeason@sinenomine.net> writes:

> No, krb5-config --deps doesn't exist in any release of heimdal I'm aware
> of (1.5.3 didn't seem to have it). And M=C3=A5ns is using heimdal 1.2.1,
> which certainly does not have --deps (discussed briefly offline).

windlord:~> krb5-config.heimdal --deps --libs
-L/usr/lib/i386-linux-gnu/heimdal -lkrb5 -lhx509 -lcom_err -lhcrypto -lasn1=
 -lwind -lheimbase -lroken -lcrypt -pthread -lpthread -ldl -lresolv -pthrea=
d -lpthread
windlord:~> krb5-config.heimdal --libs
-L/usr/lib/i386-linux-gnu/heimdal -lkrb5
windlord:~> krb5-config.heimdal --version
heimdal 1.5.99

So it does exist in Heimdal, but it's apparently more recent than I
thought.  I know Derrick ran into this, but that was probably with Mac OS
X.  Maybe Macs acquired --deps sooner than the widely used UNIX releases?

> Well that's a little strange. Running this manually and removing
> arguments reveals that Solaris Studio doesn't like -pthreads (it
> interprets it as the options -p, -h, etc, and obviously -h is not
> correct). And krb5-config does indeed say -pthreads for krb5-config
> --libs.

Aha.

> So, what is the avenue for fixing this? Should heimdal not be giving us
> -pthreads for --libs? (and does it avoid that, in future versions?)

No, it's required to get proper threading behavior, I believe.

> Does newer rra-c-util strip it out?

No, nor will it; the whole point of using krb5-config is that we trust
krb5-config, and I don't know the implications of not using -pthreads nor
want to take responsibility for second-guessing the Kerberos
configuration.

> Should we strip it out?

Maybe; it might make sense to strip it after the fact (outside of the
imported macros) when you know you're using Solaris cc.  Do you care about
threading behavior for any of the places you link with Kerberos libraries?

Really, the actual answer is that people should use consistent compiler
environments or they're going to be in for a world of hurt.  In other
words, build OpenAFS with the same compiler that you built Heimdal with
and then it would work.  Easier said than done in 1.6, of course; that's
OpenAFS's bug, not the user's, because we force a compiler that people are
not using for other things on their system.  That in turn is because we
force the compiler for all of OpenAFS just because of the kernel modules.

> Should the manual libkrb5 probing work after the 'krb5-config --libs'
> sanity check fails?

Yes.  In the absence of --enable-reduced-depends, the point of the manual
probing is to try to get all of the libraries that would be required for
static linkage.  There are a bunch of new ones that were introduced, so
there should be more cases like:

     AC_SEARCH_LIBS([roken_concat], [roken])

for the other Heimdal libraries.  Also, the Heimdal libraries need to be
stuck into something other than rra_krb5_extra; it looks like right now
we're linking with libroken even if we end up discovering MIT libraries,
which is wrong.

I can see how to fix this, I think, but what would help is if someone
would research the additional libraries I should be probing for and what
symbols (like roken_concat) are good ones to look for.

Although even if it does manage to find the libraries required to get
things to link, the threaded behavior would still be wrong.  I'm not sure
if we care for any of the code that's in OpenAFS.  The MIT manual probing
does check for -lpthreads and -lpthread because MIT needed that in some
cases, but I don't know if just linking and not using -pthread is
sufficient on all platforms.

--=20
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>