When trying to compile the kernel portion of the latest CVS tree, I found I
needed to insert the following into the Makefile in the ../linux/fs/xfs
directory. I get
ld -m elf_i386 -r -o xfs.o xfsrtstubs.o dmapi/dmapi.o xfs_dmapi.o xfs_dquot.o
xfs_trans_dquot.o xfs_dquot_item.o xfs_qm_syscalls.o xfs_qm.o xfs_alloc.o
xfs_alloc_btree.o xfs_attr.o xfs_attr_fetch.o xfs_attr_leaf.o xfs_bit.o
xfs_bmap.o xfs_bmap_btree.o xfs_btree.o xfs_buf_item.o xfs_da_btree.o xfs_dir.o
xfs_dir2.o xfs_dir2_block.o xfs_dir2_data.o xfs_dir2_leaf.o xfs_dir2_node.o
xfs_dir2_sf.o xfs_dir2_trace.o xfs_dir_leaf.o xfs_error.o xfs_extfree_item.o
xfs_fsops.o xfs_ialloc.o xfs_ialloc_btree.o xfs_iget.o xfs_inode.o
xfs_inode_item.o xfs_iocore.o xfs_itable.o xfs_dfrag.o xfs_log.o
xfs_log_recover.o xfs_macros.o xfs_mount.o xfs_rename.o xfs_trans.o
xfs_trans_ail.o xfs_trans_buf.o xfs_trans_extfree.o xfs_trans_inode.o
xfs_trans_item.o xfs_utils.o xfs_vfsops.o xfs_vnodeops.o xfs_rw.o macstubs.o
linux/linux_xfs.o
ld: cannot open dmapi/dmapi.o: No such file or directory
make[2]: *** [xfs.o] Error 1
make[2]: Leaving directory `/home/jt/Coding/linux-2.4-xfs/linux/fs/xfs'
make[1]: *** [_modsubdir_xfs] Error 2
make[1]: Leaving directory `/home/jt/Coding/linux-2.4-xfs/linux/fs'
make: *** [_mod_fs] Error 2
Sure enough the /dmapi subdirectory was there, but there was no dmapi.o inside
it.
I cut out a portion from an older ../linux/fs/xfs/Makefile and slapped it into
the new ../linux/fs/xfs/Makefile and now the modules compile.
subdir-$(CONFIG_XFS_FS) += linux
#subdir-$(CONFIG_XFS_GRIO) += grio
subdir-$(CONFIG_XFS_DMAPI) += dmapi
# added to make dmapi.o get compiled
ifneq ($(CONFIG_XFS_DMAPI),)
subdir-$(CONFIG_XFS_FS) += dmapi
endif
Thinking this is vaguely reminiscent of Steve Lord's quick fix for the grio
problem mentioned earlier today (see the #subdir-$(CONFIG_XFS_GRIO) += grio
line above, I thought I'd see if this is related, a stupid mistake on my part,
or whatever.
Your mileage may vary...
--
John M. Trostel
Linux OS Engineer
Connex
jtrostel@xxxxxxxxxx
|