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

[Russ Allbery]

Marcus Watts <mdw@umich.edu> writes:

> I meant to ask about this:

> Russ Allbery <rra@stanford.edu> had written:

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

> Which "other stuff" is that?  Do you want that "other stuff" in
> libafsauthent too?  Or elsewhere?

The current set of libraries required by the AFS Perl module are:

    -lbos
    -lvolser
    -lvldb
    -lafsrpc
    -lafsauthent
    -lcmd
    -lusd
    -laudit
    -lutil
    -lutil -lafsrpc -lutil
    -lutil -lafsauthent -lutil

The last bit is due to various annoying symbol resolution issues that may
or may not still apply.

I would like to be able to build the AFS Perl module against shared
libraries.  I have not formed an opinion about what shared libraries that
additional code belong in.

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

> What are you looking for here?  What do you expect symbol versioning to
> do?

I expect symbol versioning to do what symbol versioning does, namely to
provide a mechanism for maintaining a stable ABI even when introducing new
function signatures so that the library ABI doesn't have to be changed
unnecessarily and so that the SONAME can remain fairly stable.  A stable
SONAME is important for packaging to avoid unnecessary shared library
transitions and backward compatibility issues when building related
programs.  There are lots of web pages out there about what symbol
versioning is used for; I want it for all of the standard reasons.

> Do you expect this to affect anything beyond the text in error messages?

Yes.

> Are you talking about the src/shlibafs{rpc,authent}/mapfile* files found
> in the release source?

Those files are where you would implement symbol versioning if we were
doing it, which we aren't currently.

> Assuming I understand what you're talking about with SONAME, that got
> fixed in 1.4 between 1.4.0 & 1.4.1, and in 1.5 before 1.5.5.

Ah, indeed.  I was looking at the wrong thing.  (I thought I'd remembered
having that fix pulled up, but then when I looked at the Makefile, I
thought it was still broken.)

> Also, how do you expect this to work under aix, ms windows, hpux, and
> macosx?

I expect it to be irrelevant to Windows, which has its own ways of
handling these sorts of issues and uses a separate build system anyway.

On those other platforms, I expect it to work the same way that it does
now, namely poorly, until such time as people care enough about those
platforms to do the equivalent work using their native functionality.  If
they don't have this functionality, oh well, they lose.

AIX doesn't care about the issue that I care about because all code on AIX
is PIC and therefore statically linking AFS libraries into a dynamic Perl
module isn't as much of an issue.

On HP-UX, where this is an issue, I guess they'll have to build their AFS
code PIC if they want to use the AFS Perl module until such time as they
have a less broken shared library implementation.  Oh well.

I don't know Mac OS X well enough to speculate about what issues it may or
may not have in this area, or whether anyone builds the AFS Perl module on
Mac OS X.

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