On Mon, Jul 22, 2013 at 7:43 PM, Dave Chinner <david@xxxxxxxxxxxxx> wrote: > On Sun, Jul 21, 2013 at 02:23:39AM -0400, Michael L. Semon wrote: >> On 07/19/2013 02:24 AM, Dave Chinner wrote: >> > Hi folks, >> > >> > The following mass of patches is my current patch queue I have >> > pending for the 3.12 cycle. >> >> OK, it seems to be going okay: The PC is still functioning, even on >> a CRC-enabled / partition. The `git am` session had these anomalies: >> >> # Patch #5 >> Applying: xfs: separate dquot on disk format definitions out of xfs_quota.h >> /usr/src/kernel-git/linux/.git/rebase-apply/patch:138: trailing whitespace. >> * This header file defines all the on-disk format definitions for >> warning: 1 line adds whitespace errors. >> >> # Patch #15 >> Applying: xfs: move getdents code into it's own file >> /usr/src/kernel-git/linux/.git/rebase-apply/patch:1266: new blank line at EOF. >> + >> warning: 1 line adds whitespace errors. >> >> ######## >> There were build errors as well with gcc-4.8.1: >> >> CC fs/xfs/xfs_inode_fork.o >> fs/xfs/xfs_inode_fork.c:43:23: fatal error: xfs_utils.h: No such file or directory >> #include "xfs_utils.h" >> ^ >> compilation terminated. >> make[2]: *** [fs/xfs/xfs_inode_fork.o] Error 1 >> make[1]: *** [fs/xfs] Error 2 >> make: *** [fs] Error 2 >> # next try... >> CC fs/xfs/xfs_inode_fork.o >> fs/xfs/xfs_inode_fork.c:49:26: fatal error: xfs_vnodeops.h: No such file or directory >> #include "xfs_vnodeops.h" > > Ah, I thought I caught all of them. I use a rsync'd build tree, and > I don't use --delete because that removes all the object files. > Hence sometimes I end up with "stale files" that have been removed > from the source tree but don't get removed from the build tree and > so the build doesn't fail. > > (I thought I added a "git clean -f -d" to my build script, but on > review, that only went into the userspace builds....) This was a breeze, anyway. Good work! >> --- a/fs/xfs/xfs_log_rlimit.c >> +++ b/fs/xfs/xfs_log_rlimit.c >> @@ -137,7 +137,8 @@ xfs_log_calc_minimum_size( >> * it up to lsunit boundary if lsunit is specified. >> */ >> if (lsunit) >> - min_logblks = roundup(BTOBB(max_logres), lsunit) + 2 * lsunit; >> + min_logblks = roundup((int)BTOBB(max_logres), lsunit) >> + + 2 * lsunit; > > Why did you need that one change? This fixes a build error with gcc-4.8.1 to do with the roundup() function and calling something like __divdi3. The code compiles without the cast, but without the cast, one of the final kernel link stages fails. include/linux/kernel.h from the kernel source mentioned something about it for gcc-3.3 needing a workaround. I came up with a (const int) cast to kludge xfs_log_rlimit.c. [Without the kernel comments, I wouldn't have found the answer on my own.] Jeff reduced it to just (int), and it works, but I never got his final answer on whether it was the best solution. Should somebody else come across the same issue with gcc-4.8.1--especially on something other than 32-bit x86--I'll push this idea with more confidence. Sorry for the omitted explanation! Michael _______________________________________________ xfs mailing list xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
