Maybe something as simple as adding a build option to the openafs configure --with-libkopenafs-only compile and link only the objs that you need something like what goes into libsys.a currently, that way it would stay in sync with the distribution.
In thinking of a problem I am currently working on, I have been having problems getting header files from SGI for a older Altix running SuSe, So I can't build openafs for it. It does have a old copy of Hidemal on it and a libkafs.a , if I link against that and finaly get 1.4.11 up and running will that create a incompatibility with the "new in 1.4.11" linux PAG handeling? If so is there a version of libkopenafs that can be build with 1.4.11 , if not maybe use Russ Allbery's compatibility package in kstart? Mike Coyne -----Original Message----- From: Derrick Brashear [mailto:sha...@gmail.com] Sent: Friday, February 19, 2010 6:15 PM To: Mike Coyne Cc: Russ Allbery; openafs Info Subject: Re: [OpenAFS] Removing the ability to change the PAG of the parent [openafs-info-admin@ removed from CC list; is one of you using Lotus Notes?= On Fri, Feb 19, 2010 at 4:08 PM, Mike Coyne <mike.co...@paccar.com> wrote: > What also may be nice if if libkopenafs along with the wrappers can be ma=e > to compile stand alone so it could be more easly be linked and distrib=ted > to possibly systems with out afs installed, similary to the libkafs.a =n > your kstart package but with out the requirement for afs to be pre-instal=ed > for some non-linux systems ? That's possibly doable; You'd not be able to get pts lookups and so you'd not have Tokens for AFS id (number) but instead just Tokens, but that's not reliable anyway. _______________________________________________ OpenAFS-info mailing list OpenAFS-info@openafs.org https://lists.openafs.org/mailman/listinfo/openafs-info
