fs/zfs/icp/illumos-crypto.c:37:10: fatal error: sys/crypto/impl.h: No such file or directory - Linux v5.6 and ZFS v0.8.4 #10379
Comments
|
I just tried to recompile v5.5.13 with ZFS v0.8.4, which also failed. In addition, I recompiled .5.5.13 with ZFS v0.8.3 just now to indicate that nothing else is broken, and that executed successfully. |
tsjk
changed the title
behlendorf
added
the
Type: Building
|
Adding the make parameters seems to work this around - it then compiles, and I'm running the new kernel, with functioning ZFS pools (including the rootfs one). Some of my Makefiles in the kernel source directory must be off somehow. I still think that this is a breakage in ZFS, but it might be something that the Gentoo ebuild does wrong. |
|
I've run into a similar problem. It seems that in 0.8.3, the generated Makefile under For example:
I think this is ZFS's mistake: relying on a path relative to the current kernel source directory in generated Makefiles is the right approach, as it should be possible to move a kernel source tree from one place to another and still be able to build the zfs kernel builtin. This is a regression. |
|
Commit 65635c3 changed this, maybe @nivedita76 can comment? |
|
That was to work around a problem when kernel build dir != kernel source dir. The original issue #9988 has some more details. Is the tmp directory where the zfs source was unpacked getting deleted before you build your kernel? I use the builtin setup on gentoo, but I don't use the ebuild, I just manually checkout the source from git and build. I think a better solution than what I had earlier suggested, at least for in-kernel build, might be to use However, I am not sure how that will impact DKMS builds. |
|
This is how I build it, with appropriate defines for KSRC/KOBJ/KCFG/ZSRC/NJOBS. |
Yes. It'd be the case with an ebuild, but it's also the case for any setup in which you'd configure in some place, and build in another. Kernel source directories are always self-contained and portable. I don't think ZFS should break these assumptions. My specific use case for this is generating a ZFS-builtin patch that can automatically be applied to any kernel within a kernel series over its lifetime: a patch generated from diff'ing a vanilla |
|
Does this patch work for you? Outside of icp, the rest of the include dirs actually seem to get overridden by copy-builtin creating fs/zfs/Kbuild (to reference $(srctree), top of kernel source), though the original Makefile in module/Makefile.in uses abs_top_srcdir. For consistency, it might be better to just include the icp include directory as well in copy-builtin? |
|
The patch you posted @nivedita76 seems to work for me. Thanks! After your comment, I checked my generated zfs patch, and indeed, the original temporary build dir (the one from which While I haven't noticed any build-time or runtime breakage from this, this would seem brittle. Maybe an experienced ZFS contributor should chime in, both on this and on your proposed inclusion of icp in |
I agree, maybe @behlendorf can shed some light on this? |
|
I think adding the |
|
There's another issue with @gcs-github's workflow in master. Commit bced7e3 moved out everything from the spl directory into os/linux/spl, and now has a stub Makefile that includes a reference to the zfs repository. i.e. module/spl/Makefile.in includes So if the zfs source directory is gone, builtin still doesn't work. Is there a reason we still have the module/spl directory rather than directly using module/os/linux/spl? |
|
@behlendorf I can send a PR for the copy-builtin change for now, but it's not a complete fix for master due to the issue in previous comment. |
|
@nivedita76 I'm not seeing the other issue, could you be more specific. |
|
@behlendorf , if you configure using --enable-linux-builtin, do copy-builtin and then move/delete the ZFS source directory, the kernel can't be built. This is what @gcs-github is trying to achieve, i.e. eliminate dependency on the ZFS tree once the configured sources have been copied into the kernel directory. My commit to the icp include dir is one issue, but there are more issues beyond that which prevent it. This is because fs/zfs/spl/Makefile tries to include os/linux/spl/Makefile from the ZFS directory rather than the copy that's in the kernel tree. Same thing for fs/zfs/zfs/Makefile which includes os/linux/zfs/Makefile. |
|
Basically if you take the recipe in #10379 (comment), and insert |
|
The fix for this was merged. Thanks for the patch @nivedita76. |
The linux module can be built either as an external module, or compiled
into the kernel, using copy-builtin. The source and build directories
are slightly different between the two cases, and currently, compiling
into the kernel still refers to some files from the configured ZFS
source tree, instead of the copies inside the kernel source tree. There
is also duplication between copy-builtin, which creates a Kbuild file to
build ZFS inside the kernel tree, and the top-level module/Makefile.in.
Fix this by moving the list of modules and the CFLAGS settings into a
new module/Kbuild.in, which will be used by the kernel kbuild
infrastructure, and using KBUILD_EXTMOD to distinguish the two cases
within the Makefiles, in order to choose appropriate include
directories etc.
Module CFLAGS setting is simplified by using subdir-ccflags-y (available
since 2.6.30) to set them in the top-level Kbuild instead of each
individual module. The disabling of -Wunused-but-set-variable is removed
from the lua and zfs modules. The variable that the Makefile uses is
actually not defined, so this has no effect; and the warning has long
been disabled by the kernel Makefile itself.
The target_cpu definition in module/{zfs,zcommon} is removed as it was
replaced by use of CONFIG_SPARC64 in
commit 70835c5 ("Unify target_cpu handling")
os/linux/{spl,zfs} are removed from obj-m, as they are not modules in
themselves, but are included by the Makefile in the spl and zfs module
directories. The vestigial Makefiles in os and os/linux are removed.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Closes openzfs#10379
Closes openzfs#10421
cmd/zpool and lib/libzutil Makefile's use -I., which won't work with a VPATH build. Replace it with -I$(srcdir) instead. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Closes openzfs#10379 Closes openzfs#10421
The linux module can be built either as an external module, or compiled
into the kernel, using copy-builtin. The source and build directories
are slightly different between the two cases, and currently, compiling
into the kernel still refers to some files from the configured ZFS
source tree, instead of the copies inside the kernel source tree. There
is also duplication between copy-builtin, which creates a Kbuild file to
build ZFS inside the kernel tree, and the top-level module/Makefile.in.
Fix this by moving the list of modules and the CFLAGS settings into a
new module/Kbuild.in, which will be used by the kernel kbuild
infrastructure, and using KBUILD_EXTMOD to distinguish the two cases
within the Makefiles, in order to choose appropriate include
directories etc.
Module CFLAGS setting is simplified by using subdir-ccflags-y (available
since 2.6.30) to set them in the top-level Kbuild instead of each
individual module. The disabling of -Wunused-but-set-variable is removed
from the lua and zfs modules. The variable that the Makefile uses is
actually not defined, so this has no effect; and the warning has long
been disabled by the kernel Makefile itself.
The target_cpu definition in module/{zfs,zcommon} is removed as it was
replaced by use of CONFIG_SPARC64 in
commit 70835c5 ("Unify target_cpu handling")
os/linux/{spl,zfs} are removed from obj-m, as they are not modules in
themselves, but are included by the Makefile in the spl and zfs module
directories. The vestigial Makefiles in os and os/linux are removed.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Closes #10379
Closes #10421
cmd/zpool and lib/libzutil Makefile's use -I., which won't work with a VPATH build. Replace it with -I$(srcdir) instead. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Closes #10379 Closes #10421
The linux module can be built either as an external module, or compiled
into the kernel, using copy-builtin. The source and build directories
are slightly different between the two cases, and currently, compiling
into the kernel still refers to some files from the configured ZFS
source tree, instead of the copies inside the kernel source tree. There
is also duplication between copy-builtin, which creates a Kbuild file to
build ZFS inside the kernel tree, and the top-level module/Makefile.in.
Fix this by moving the list of modules and the CFLAGS settings into a
new module/Kbuild.in, which will be used by the kernel kbuild
infrastructure, and using KBUILD_EXTMOD to distinguish the two cases
within the Makefiles, in order to choose appropriate include
directories etc.
Module CFLAGS setting is simplified by using subdir-ccflags-y (available
since 2.6.30) to set them in the top-level Kbuild instead of each
individual module. The disabling of -Wunused-but-set-variable is removed
from the lua and zfs modules. The variable that the Makefile uses is
actually not defined, so this has no effect; and the warning has long
been disabled by the kernel Makefile itself.
The target_cpu definition in module/{zfs,zcommon} is removed as it was
replaced by use of CONFIG_SPARC64 in
commit 70835c5 ("Unify target_cpu handling")
os/linux/{spl,zfs} are removed from obj-m, as they are not modules in
themselves, but are included by the Makefile in the spl and zfs module
directories. The vestigial Makefiles in os and os/linux are removed.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Closes openzfs#10379
Closes openzfs#10421
cmd/zpool and lib/libzutil Makefile's use -I., which won't work with a VPATH build. Replace it with -I$(srcdir) instead. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Closes openzfs#10379 Closes openzfs#10421
The linux module can be built either as an external module, or compiled
into the kernel, using copy-builtin. The source and build directories
are slightly different between the two cases, and currently, compiling
into the kernel still refers to some files from the configured ZFS
source tree, instead of the copies inside the kernel source tree. There
is also duplication between copy-builtin, which creates a Kbuild file to
build ZFS inside the kernel tree, and the top-level module/Makefile.in.
Fix this by moving the list of modules and the CFLAGS settings into a
new module/Kbuild.in, which will be used by the kernel kbuild
infrastructure, and using KBUILD_EXTMOD to distinguish the two cases
within the Makefiles, in order to choose appropriate include
directories etc.
Module CFLAGS setting is simplified by using subdir-ccflags-y (available
since 2.6.30) to set them in the top-level Kbuild instead of each
individual module. The disabling of -Wunused-but-set-variable is removed
from the lua and zfs modules. The variable that the Makefile uses is
actually not defined, so this has no effect; and the warning has long
been disabled by the kernel Makefile itself.
The target_cpu definition in module/{zfs,zcommon} is removed as it was
replaced by use of CONFIG_SPARC64 in
commit 70835c5 ("Unify target_cpu handling")
os/linux/{spl,zfs} are removed from obj-m, as they are not modules in
themselves, but are included by the Makefile in the spl and zfs module
directories. The vestigial Makefiles in os and os/linux are removed.
Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov>
Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu>
Closes openzfs#10379
Closes openzfs#10421
cmd/zpool and lib/libzutil Makefile's use -I., which won't work with a VPATH build. Replace it with -I$(srcdir) instead. Reviewed-by: Brian Behlendorf <behlendorf1@llnl.gov> Signed-off-by: Arvind Sankar <nivedita@alum.mit.edu> Closes openzfs#10379 Closes openzfs#10421
System information
I get the following error during compilation:
ZFS v0.8.3 w/ Linux v5.5 worked, with the same procedure I've used quite a while (the version is new however, duh!):
After that I carry on with compilation:
Should something be done differently?
And, it is true I have no /usr/include/sys/crypto/impl.h. But there is a /usr/src/linux-5.6_p7-pf/fs/zfs/icp/include/sys/crypto/impl.h (which is amongst the kernel sources I'm trying to compile.)
The text was updated successfully, but these errors were encountered: