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

[Russ Allbery]

Marcus Watts <mdw@umich.edu> writes:
> 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".

So it's just low-level weirdness along those lines?  That doesn't really
bother me.  (And hm, doesn't the new threading model not expose things
that way any more, or am I confused?)

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

It is, yes.

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

Right, sorry.  Yes, there are cases that are even more restrictive, but
that's the common one and the one that I'm the most concerned with, since
it's directly relevant to both Perl modules and PAM modules.

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

Exactly.

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

No, I don't, because those libraries don't contain enough code to do
everything that I care about.  There's a variety of "other stuff" that
isn't included in those libraries.

Plus, until recently (and possibly still on the release branches) the
SONAME is broken on Linux, and no symbol versioning is happening.
(There's a version script.  It doesn't do symbol versioning.  It does
something else.)

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

No, really, the real problem is that I want a properly managed shared
library with ABI guarantees.  What you're talking about is also an
interesting problem, but there are various ways to get around that.  It's
far easier to deal with that than to deal with not having a proper shared
library.

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

pkgconfig is a possibly better replacement for the random *-config script
thing, but that's another discussion.

> A lot of these *-config things were probably generated by some gnu tool
> (libtool?),

You'd think so, but no, generally someone just bashed together a shell
script.

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

A solution specific to AFS is only partly helpful, and nowhere near as
helpful as AFS starting to act like the rest of the world.

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