[OpenAFS-devel] not sure what to do about rlim --- also on other 64 bit machines?

[Moritz Kiese]

On Thu, 29 Jun 2006, Christian Guggenberger wrote:

> On Thu, Jun 29, 2006 at 01:37:18PM +0200, Moritz Kiese wrote:
>> On Thu, 29 Jun 2006, chas williams - CONTRACTOR wrote:
>>
>>> In message <20060629042745.GC5860@narn.hozed.org>,Troy Benjegerdes writes:
>>>> I managed to build OpenAFS 1.4.1 on 2.6.17 (kernel.org) on a PPC64
>>>> machine, using
>>>> "CFLAGS='-m64' ./configure
>>>> --with-linux-kernel-headers=/usr/src/linux-2.6.17"
>>>
>>> i am surprised that is sufficient.  2.6.17 seems to have changed the
>>> way KBUILD_BASENAME is handled and requires a new macro KBUILD_STR.
>>
>> Please forgive my ignorance, but is the compilation error I'm seeing:
>>
>> /usr/src/openafs-1.5.2/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_vnop_flock.c:176:
>> error: struct task_struct has no member named p_opptr
>>
>
> this is on SuSE 10.1, x86_64, isn't it ?

Yup.

> do you really need version 1.5.2 ? I had no problems while compiling 1.4.1 for
> Suse 10.1 (same kernel version as you referred to) here.

Lucky you ;) Here's what I do:

# export CFLAGS=-m64
# ./configure
# make

Compilation stops at
In file included from /usr/src/openafs-1.4.1/src/afs/afs_osi.h:443,
                  from /usr/src/openafs-1.4.1/src/rx/rx_clock.h:88,
                  from /usr/src/openafs-1.4.1/src/rx/rx.h:35,
                  from /usr/src/openafs-1.4.1/src/afs/afsincludes.h:26,
                  from 
/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_analyze.c:36:
/usr/src/openafs-1.4.1/src/afs/LINUX/osi_machdep.h:55:2: error: #error Not 
sure what to do about rlim (should be in the Linux task struct somewhere....)

So that's easy to handhack to
 	#define TASK_STRUCT_RLIM signal->rlim
Once that is done I'm hanging at
/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_osi.c: In 
function afs_osi_TraverseProcTable:
/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_osi.c:828: 
error: implicit declaration of function for_each_task
/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_osi.c:828: 
error: expected ; before if

for_each_task seems to have taken the path of all mere humans, but there's 
a for_each_process macro seemingly (?) doing the same thing, for which 
somehow the #ifdef fails, so I change that as well.

Due to SMP I'm getting stuck because of non-existant TASK_ZOMBIE next, 
which are of course EXIT_ZOMBIE. Getting rid of those leads me to my new 
old final error

/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_vnop_flock.c: 
In function lockIdcmp2:
/usr/src/openafs-1.4.1/src/libafs/MODLOAD-2.6.16.13-4-smp-MP/afs_vnop_flock.c:175: 
error: struct task_struct has no member named p_opptr

Bummer. And if you tell me now, this is all SuSE's fault who am I to 
disagree? Seriously: If you think this is related to a f*** up toolchain 
curtesy of SuSE, I'll have to persuade our computer guy to use something 
else, which effectively puts yet another workstation under my 
(non-) administration (which I dislike).

>> at all related to the modifacations Troy described (skipping syscall table
>> probeing)?
>>
> no, this is a ppc64 (Linux on 64bit powerpc processors, e.g. POWER3/4/5,
> ppc970/G5) only problem, which happens with openafs newer than
> 1.4.1-rc10.

OK. That's what I thought, but hey, I'm never sure w/ Linux.

Thanks for your input,
 	Moritz, who is somehow reminded of compiling X11 extensions in the 
early 90s. But then this is just a personal feeling. At least compilation 
is way faster that on a SS LX.