[OpenAFS] jafs et al
Tue, 13 Mar 2007 20:07:42 -0500
Russ Allbery <email@example.com> had replied:
> Derrick J Brashear <firstname.lastname@example.org> wrote:
> > On Tue, 13 Mar 2007, Peter Somogyi wrote:
> >> IIRC I had problems on platforms like ppc and s390x with pic stuff
> >> (one crashes runtime if you don't turn on pic, other didn't allow
> >> mixing pic and non-pic or something like that). So please modify _only_
> >> that platform which you are testing.
> > So, why not just not mix pic and non pic and still only build what you
> > need pic?
> It's worth noting that the AFS Perl module has the same problem, and this
> is the reason why it's not yet packaged for Debian. All the libraries it
> links against would need to be built PIC, and unfortunately that includes
> various libraries that are not part of libafsauthent or libafsrpc.
> I've looked a couple of times at what would be involved in building the
> right things PIC, and I think it's doable, but it's annoying. And I'm not
> sure if it's enough stuff for worries about performance problems to arise.
I don't think there's any one best answer. There's actually several
pic vs. nonpic
lwp vs. pthread
user vs kernel mode vs. "user kernel" mode
although these aren't strictly independent. Perl has its
own special brand of weirdness, especially in regards to
threading, & tossing mit kerberos 5 and glibc into the mix
can produce fascinating but bad behavior. In some environments
(many?) - linking against pthread would be very attractive,
but not on linux. In some environments (many?) - mixing pic
and non-pic code is kosher, but apparently not ibm big-endian iron.
I think for openafs, it would make sense to have a "enable-pic" configure
flag - that could turn on pic mode globally. That could be used to
build static libraries for pam, perl & whatever as one relatively
clean approach, without compromising server performance. On some
architectures (pretty much anything that has sun inspired shared
libraries) it's easy and good to build "libXXX_pic.a" files along-side
the ".so.X" shared library. It's all the same ".o" files in the
library build directory, just bound a different way.
For perl & pam, I think it would be nice to have options to turn
pthreads on or off, in those packages. That would make it easier to
select the appropriate choice for the local environment.