From: Stefan van der Eijk (stefan_at_eijk.nu)
Date: Fri 10 May 2002 - 20:39:08 BST
James,
>On Tue, 7 May 2002, Stefan van der Eijk wrote:
>
>
>>Yesterday's error seems to be gone (I did some tweaking in the patch,
>>the patch was attached to my post yesterday), but a new one has come up:
>>
>>/usr/bin/gcc-3.0.4 -D__KERNEL__ -I/home/cooker/RPM/BUILD/linux/include -Wall -Wstrict-prototypes -Wno-trigraphs -O2 -fno-strict-aliasing -fno-common -fomit-frame-pointer -pipe -mpreferred-stack-boundary=2 -march=i586 -DMODULE -DMODVERSIONS -include /home/cooker/RPM/BUILD/linux/include/linux/modversions.h -nostdinc -I /usr/lib/gcc-lib/i586-mandrake-linux-gnu/3.0.4/include -DKBUILD_BASENAME=inode -c -o inode.o inode.c
>>inode.c: In function `reiserfs_new_inode':
>>inode.c:1528: `EXT2_IMMUTABLE_FL' undeclared (first use in this function)
>>inode.c:1528: (Each undeclared identifier is reported only once
>>inode.c:1528: for each function it appears in.)
>>inode.c:1590: `S_IMMUTABLE' undeclared (first use in this function)
>>inode.c: In function `sd_attrs_to_i_attrs':
>>inode.c:2127: `EXT2_IMMUTABLE_FL' undeclared (first use in this function)
>>inode.c:2128: `S_IMMUTABLE' undeclared (first use in this function)
>>inode.c: In function `i_attrs_to_sd_attrs':
>>inode.c:2145: `S_IMMUTABLE' undeclared (first use in this function)
>>inode.c:2146: `EXT2_IMMUTABLE_FL' undeclared (first use in this function)
>>make[2]: *** [inode.o] Error 1
>>make[2]: Leaving directory `/home/cooker/RPM/BUILD/linux/fs/reiserfs'
>>make[1]: *** [_modsubdir_reiserfs] Error 2
>>make[1]: Leaving directory `/home/cooker/RPM/BUILD/linux/fs'
>>make: *** [_mod_fs] Error 2
>>error: Bad exit status from /home/cooker/tmp/rpm-tmp.46847 (%build)
>>
>>
>
>These look like the changes to the DEFINES that are in the 2.4.19-pre
>kernels where EXT2_IMMUTABLE_FL becomes EXT2_IMMUTABLE_FILE_FL and
>EXT2_IMMUTABLE_LINK_FL depending ? Dido for S_IMMUTABLE to
>S_IMMUTABLE_{FILE|LINK}. Look in include/linux/fs.h for them.
>
Disclaimer: I've got no programming skills, and am doing this by trying
to think logically...
The thing that puzzles me is that this is happening in the reiserfs
directory, which isn't touched by the ctx patch. Does this mean that if
reiserfs (and the other filessytems that might bork after this one is
fixed) need to be patched in order to cope with the changes that are
made against include/linux/fs.h ?
Stefan