[OpenAFS] Re: 1.6.2 compilation notes, Sol10

Andrew Deason adeason@sinenomine.net
Thu, 28 Mar 2013 14:51:58 -0500

On Thu, 28 Mar 2013 11:50:53 -0700
Russ Allbery <rra@stanford.edu> wrote:

> > 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.

For the linker? I thought for linking all it did was -lpthread (though
it may do other things for the preprocessor or compiler). It's not a
valid option to GNU ld, either.

> > 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?

afsio is threaded, but I think everything we do with krb5 is before any
of the threads get started. I could be wrong about that, though.

But I don't think afsio is as important as aklog and friends. If the
answer is to disable afsio krb5 support for some situations, that
doesn't seem so bad to me.

> 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.

heimdal also doesn't compile with Solaris Studio, so it's not all ours
:) (at least, not that version, and not "easily", though I didn't try
very hard)

It doesn't seem great to me to require the same compiler for shared
libraries; aside from "layering violation" objections or whatever, it's
just not practical in many environments. But if gcc requires -pthreads,
and Studio requires -mt -lpthread, then obviously you can't give the
same flags for both. (which suggests to me maybe it shouldn't be in
--libs, but a --am-i-threaded or something, but nevermind) Or if it
works when pthreads are not linked in, then it shouldn't be in libs at
all, since the calling build system will pass the necessary stuff for
multithreaded code if it wants it. For OpenAFS, it seems like we should
be able to strip it out and put in threaded-ness according to our own
logic. Do we need to always add -lpthread etc, even if we want to use
libkrb5 in a non-threaded program?

And of course, this isn't really a gcc vs Solaris thing, it's that
turning on threads involves different flags everywhere. Or different
commands to run: xlc_r vs xlc as far as I know.

> > Should the manual libkrb5 probing work after the 'krb5-config
> > --libs' sanity check fails?
> 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.

I can get this to work, but I assume from your other email you want this
in OpenAFS and not rra-c-util. And possibly, specifically passed to
aklog, and not all of our libkrb5 users.

Andrew Deason