About this list Date view Thread view Subject view Author view Attachment view

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


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Wed 06 Nov 2002 - 07:03:40 GMT by hypermail 2.1.3