[OpenAFS-devel] Re: [OpenAFS] jafs et al

[Marcus Watts]

Russ Allbery <rra@stanford.edu> writes:
> Er, linking against pthread is very attractive to me on Linux.  What am I
> missing?

Depending on the version of linux (& glibc) you're more or less
likely to get a "different process" per thread, which affects
things like "kill", "wait", and "ps".

> 
> > In some environments (many?) - mixing pic and non-pic code is kosher,
> > but apparently not ibm big-endian iron.
> 
> Mixing PIC and non-PIC code is not kosher in general.  There just happens
> to be a few interesting exceptions where you can get away with it,
> including x86 Linux.  You can't mix PIC and non-PIC on amd64 Linux, let
> alone weirder stuff.

I think this is to some fair extent an abi issue.  Also, it's not as
true as all that even on amd64.  On amd64, even by default, non-pic
executables link dynamically against pic shared libraries.  Non-pic
executables can also be statically linked against pic objects.  What
breaks is linking non-pic code into shared libraries and objects.
Indeed, on most machines, non-pic code in shared libraries is frowned
upon, and amd64 is merely enforcing a very common policy.  It happens
to work with i386/gnu, and that's the real anomaly here.  An archaic
similar example is sunos 4.0 on 68k; yes, you could link non-pic
objects into a shared library.  At run-time, ld.so handle relocation
records for the "read-only" text segment by write-enabling pages and
and adjusting references.

And then there are architectures where "pic" always happens,
such as AIX, or where dynamic linking (nearly) always happens, like
solaris 64-bit, or darwin, ...

> 
> > 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.
> 
> Well, that I could do now.  But building AFS twice and then extracting
> libraries from the second build is really obnoxious from a packaging
> perspective, because now you also have to chase every package that depends
> on AFS libraries and get them to update what libraries they're linking
> with and tack _pic on to the end, or you have to have two directories of
> AFS libraries, or you have to install server binaries built with different
> libraries than you ship in the dev package.
> 
> It's all doable and all ugly.

I think this is a bit cleaner than Peter Somogyi's approach of just
always doing "-fPIC" on selected architectures.  But not much.
And yes, it probably does complicate packaging.

> 
> The clean approach from a Linux perspective is to have a shared library
> with a versioned API that you can link against.  It saves overhead,
> reduces memory usage, and makes packaging far cleaner.  It's just a lot
> more work getting it right and keeping it right.

You've got that now.  They're called "libafsrpc.so" and "libafsauthent.so".
It's got the "not everything is pthread-safe" problem that Jeff alluded
to, plus a mild case of the kitchen sink problem.

The real problem here is:
	given X things the application needs or wants,
	generate Y includes and defines at compile time.
	and Z libraries to append to the link link.
This is not quite as exotic as all that.  MIT k5 has a "krb5-config"
command that helps with this.  In fact, on a random debian machine here
at work, there are 39 things called /usr/bin/*-config that appear to be
mostly the same thing for various packages.

A lot of these *-config things were probably generated by some gnu tool
(libtool?), but AFS will probably need its own unique thing.  I envision
something that might work like this:

	% openafs-config --libs pt ka
	-L/usr/afs/lib -lprot -lkauth -lubik -lrxkad -lrx -ldes -lcom_err -lafsutil
	% openafs-config --cflags pthread
	-DAFS_PTHREAD_ENV
	% openafs-config --libs pt pthread
	-lafsauthent -lafsrpc

keywords: pt pthread ubik rx ka comerr pic static volser vl
cmd acl auth bos budb ...

This can know about "_pic", whether a given architectures supports
or requires pic, special options to pass to the compiler to make
compatible objects and libraries, etc.  I believe this would make
packaging much simpler, and would also make it less necessary
for application developers to know which libraries are needed by
which parts of openafs.  That's going to become more important
as things like strlcpy references in com_err, rxgk or rxk5, kerberos 5,
etc. enter the picture.

...

					-Marcus