Closed andrewts closed 13 years ago
Did you run configure against the correct kernel sources? It looks like ./configure failure to detect the evict inode hook in your 2.6.38 kernel. You might do a 'make distclean && ./configure && make' again. Also you can check that HAVE_EVICT_INODE is defined in your zfs_config.h file which is generated after configure.
./configure --with-linux=/usr/src/linux-2.6.38-hardened-r6:
... checking whether sops->evict_inode() exists... no ...
zfs_config.h says:
/* sops->evict_inode() exists */ /* #undef HAVE_EVICT_INODE */
I guess it's got something to do with kernel config.
I traced the problem to the difference between kernel headers. /usr/src/linux/include/linux/fs.h:
--- station-fs.h 2011-03-15 04:20:32.000000000 +0300 +++ server-fs.h 2011-06-27 21:21:23.000000000 +0400 ..output skipped.. - void (*evict_inode) (struct inode *); + void (* const evict_inode) (struct inode *); ..output skipped..
I've changed it manually (ugh.. fingers crossed) and compilation went without a single problem. Will now try to recompile the kernel.
Why do your headers differ from upstream? Is this a local gentoo mod for 'hardened' kernels? If so we may need to make the check in config/kernel-evict-inode.m4 a bit smarter to detect this.
Yeah, it is a patchset from hardened gentoo team with a lot of security enhancements (Grsecurity, SELinux etc.). I've been told it's good to use this kernel on a server.
CentOs 5.5, yum updates current, kernel.org 2.6.36.4. After running ./configure, ran a home brew script that searched the zfs-0.6.0-rc4 tree (now the -rc5 tree) and took out all "Wno" references. A make rpm then succeeded. This is on a freshly extracted zfs tree. Haven't researched the harm in doing this.
That's no harm in doing this, it's safe. Is this an acceptable work around for you until you migrate to something newer? If so can we close the issue?
Sure. I know my kernel is in the range of "working kernels" and is stock from kernel.org. Knowing that error free is a goal, just reporting what I found out. Haven't read the bug reports to a point of understanding. Are you guessing an issue on the compile side or the kernel source side? From the "something newer statement" I'm presuming CentOS/RedHat 5.5 is "old"? Not using any Fedora as I need the base OS to be stable. The latest I have is a Scientific Linux 6.x... also based upon RedHat.
Following your development roadmap carefully. Looking to move from a Solaris ZFS back to Linux. We are looking for ZFS and IBM/HP/Quantum LTFS/FUSE to live on the same system. If the 0.0.7 release gets .zfs visible, I'll be awefully close to happy.
-----Original Message----- From: behlendorf [mailto:reply+i-1121182-6164f4a043a56427720c07cf976ec8e7a79c63fc@reply.g ithub.com] Sent: Thursday, July 21, 2011 2:58 PM To: Allgood, Sam Subject: Re: [zfs] compile error (in file zpl_super.c) (#296)
That's no harm in doing this, it's safe. Is this an acceptable work around for you until you migrate to something newer? If so can we close the issue?
Reply to this email directly or view it on GitHub: https://github.com/zfsonlinux/zfs/issues/296#issuecomment-1626001
The issue your hitting is on the compiler side. Your older version of gcc simply doesn't support the compiler options used by the project. More compatibility code could be added to detect that and do the right thing but frankly it's just not worth the development effort. I hear where your coming from concerning a stable base OS but I'd rather not invest in RHEL5.5 when it's already end of life. RHEL6.1 is now available as is CentOS 6.0 and Scientific Linux 6.0 both of which will be supported by ZFS. I'm personally targeting RHEL6.x for our systems at LLNL.
As for the .zfs directory I think getting that working on the local machine is quite close. Getting it working over an NFS share might take a little more time and require nfsv4, but we'll see.
Thanks for following the project so closely!
Hello Brian! I'm also using hardened-sources and i'm hitted the same problem. Changes in headers file are made by grsecurity team (not by gentoo team). Would it be possible that you spent some time in the future on this?
marcin-github: If you can you point me at the hardened source headers I can take a quick look and see what can be done. In the meanwhile, you should just be able to modify the zfs_config.h file after the ./configure step and update it so HAVE_EVICT_INODE is defined. This should avoid the build issue.
You can grab patch from homepage http://grsecurity.net/ , direct link to patch for kernel-2.6.39 is http://grsecurity.net/test/grsecurity-2.2.2-2.6.39.3-201107191826.patch (old version of patch are removing, link will be valid untill next version of patch). Thanks.
marcin-github: Please try this patch, fffafc0a3d64db7aed09cc9a88b696c8e0435d30 . It improves the autoconf check to get the correct result even with the grsecurity patched kernel.
Thanks. Configure correctly detects EVICT_INODE now. Now i;ve got problem with compilation error:
make[3]: Entering directory /usr/src/linux-2.6.39-hardened-r8' CC [M] /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.o /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c: In function ‘zpl_inode_delete’: /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:93:2: error: implicit declaration of fu nction ‘clear_inode’ /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c: At top level: /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:211:2: error: unknown field ‘clear_inod e’ specified in initializer /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:212:2: error: unknown field ‘delete_ino de’ specified in initializer /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:212:2: warning: initialization from inc ompatible pointer type /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:214:2: warning: initialized field overw ritten /var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.c:214:2: warning: (near initialization fo r ‘zpl_super_operations.put_super’) cc1: warning: unrecognized command line option "-Wno-unused-but-set-variable" make[5]: *** [/var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs/../../module/zfs/zpl_super.o] Error 1 make[4]: *** [/var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module/zfs] Error 2 make[3]: *** [_module_/var/tmp/portage/sys-fs/zfs-9999/work/zfs-9999/module] Error 2 make[3]: Leaving directory
/usr/src/linux-2.6.39-hardened-r8'
This is "tstudios'. I'm not the expert but, see my comments beginning on 07-21 with CentOS 5.5. After ./configure, I took out all references to the Wno- string with a sed script across the entire source tree. Made sure ./configure itself was still executable when this was done as my sed scripts undid a 755. All compiled okay after that. I did just recentl move CentOS 6.0. See Brian's comments after mine.
Hmm, i don't know what is the root of problem. -Wno-unused-but-set-variable shouldn't be problematic, it's just warning. I can compile zfs using gcc-4.5.3 and gcc-4.6.1(which suports unused-but-set-variable) on kernel "gentoo-sources-2.6.39" and 3.0 . I can't compile using gcc-4.5.3 on hardened-sources-2.6.39 .
Probably just me not being observant but, I see at the error your compiler is calling itself cc1 and not gcc. Again though, I never thought to notice. Just looking at the obvious, you are invoking gcc? I've been the non-expert on Solaris systems in the past couple of years to have burned myself with multiple packages.
My gcc version was 4.1.2, obviously older than yours. The 4.1.2 complained of "Warning" then failed.Anyway, this quick script run right above the source tree and right after configure got me out of the woods. Again, set 755 on 'configure' before running 'make' (line wraps are bad in this paste in): find ./zfs-0.6.0-rc5/ -type f -exec grep -H Wno {} \; | cut -d: -f1 | while read i; do cat "$i" | sed -e "s/-Wno-unused-but-set-variable//g" >> "$i".tmp; /bin/mv "$i".tmp "$i"; done
Are you sure it correctly detected evict_inode(), if it did it shouldn't even be trying to build the zpl_inode_delete() function. I would start with a clean tree, apply the patch and try again. Make sure HAVE_EVICT_INODE is defined in zfs_config.h after the configure step.
$ grep EVICT_INODE zfs_config.h #define HAVE_EVICT_INODE 1
Git is too strange for me:( I was sure this commit is in something which could be called "trunk", and i'm working on code with this commit. I was wrong. Nevermind... I've manually download config/kernel-evict-inode.m4 and configure (from this commit), and it compiles without problem:) Thanks for fix!
Wonderful, I'll get this fix merged in for the gentoo folks. Thanks for verifying it works as expected.
Kernel: 2.6.38-hardened-r6 (though system is not hardened (gentoo linux)). Latest spl installed.
I think I'm missing something in my system required for building modules, because on my desktop machine compilation went flawlessly. This is a minimalistic installation used as "home server".