configure fails to properly "checking whether kuid_t/kgid_t is available..." #653

digitalsanity · 2017-10-03T00:13:23Z

Running on arm64 Ubuntu 16.04 LTS with a 4.4.77 aarch64 kernel (Linux rock64 4.4.77-rockchip-ayufan-133 #1 SMP Thu Sep 28 10:51:45 UTC 2017 aarch64 aarch64 aarch64 GNU/Linux) and ./configure reports:

checking whether kuid_t/kgid_t is available... no

and subsequently fails building.

If I manually edit and force define HAVE_KUIDGID_T, I can compile without trouble.

behlendorf · 2017-10-03T20:49:01Z

Can you post in the relevant section of the config.log where it fails. We're testing with an older 3.14 kernel for aarch64 which does work.

digitalsanity · 2017-10-03T23:11:14Z

from console.log:

configure:17048: checking whether kuid_t/kgid_t is available
configure:17076: cp conftest.c build && make modules -C /usr/src/linux-headers-4.4.77-rockchip-ayufan-133 EXTRA_CFLAGS=-Werror-impl$
make[1]: *** [/usr/src/spl-0.7.2/build/conftest.o] Error 1
make: *** [module/usr/src/spl-0.7.2/build] Error 2
configure:17079: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "spl"
| #define PACKAGE_TARNAME "spl"
| #define PACKAGE_VERSION "0.7.2"
| #define PACKAGE_STRING "spl 0.7.2"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define SPL_META_NAME "spl"
| #define SPL_META_VERSION "0.7.2"
| #define SPL_META_RELEASE "1"
| #define SPL_META_LICENSE "GPL"
| #define SPL_META_ALIAS "spl-0.7.2-1"
| #define SPL_META_AUTHOR "OpenZFS on Linux"
| #define PACKAGE "spl"
| #define VERSION "0.7.2"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define SPL_IS_GPL_COMPATIBLE 1
| #define HAVE_ATOMIC64_T 1
| #define HAVE_SPLIT_SHRINKER_CALLBACK 1
| #define HAVE_PDE_DATA 1
| #define HAVE_SET_FS_PWD_WITH_CONST 1
| #define HAVE_3ARGS_VFS_UNLINK 1
| #define HAVE_6ARGS_VFS_RENAME 1
| #define HAVE_2ARGS_VFS_FSYNC 1
| #define HAVE_FS_STRUCT_SPINLOCK 1
|
|
| #include <linux/uidgid.h>
|
| int
| main (void)
| {
|
| kuid_t userid = KUIDT_INIT(0);
| kgid_t groupid = KGIDT_INIT(0);
|
| ;
| return 0;
| }
|
configure:17148: result: no

digitalsanity · 2017-10-03T23:14:18Z

I also created a test.c here with:

----- test.c ------------
#include <linux/uidgid.h>

kuid_t userid = 0;
kgid_t groupid = 0;

int main(){return(1);}

-----end test.c--------

this fails to compile with:

gcc -I/usr/src/linux-headers-4.4.77-rockchip-ayufan-133/include test.c
test.c:3:17: error: invalid initializer
kuid_t userid = 0;
^
test.c:4:18: error: invalid initializer
kgid_t groupid = 0;
^
however, it does compile cleanly if I remove the int initializer .. since kuid_t is a struct now..? isn't it enough that kuid_t exists?

---- start test2.c ------

#include <linux/uidgid.h>

kuid_t userid;
kgid_t groupid;

int main(){return(1);}

-------- end test2.c ----------

behlendorf · 2018-06-01T00:01:12Z

Closing. @digitalsanity I'm unable to reproduce the issue on an aarch64 odroid-c2 running Ubuntu 16.04. If this is still an issue with the latest ZFS releases please go ahead and open a new issue in zfsonlinux/zfs repository.

digitalsanity · 2018-06-01T00:35:55Z

You are able to install spl-dkms/zfs-dkms without issue? Which kernel are you using? I am now on 4.4.x with bionic 18.04 using zfs/spl 0.7.5-1ubuntu16 from bionic-updates arm64.. I've had to do the same process with jessie/stretch/xenial and now bionic so far .. but maybe it's something with the kernel?

It really comes down to making sure configure shows:

checking whether kuid_t/kgid_t is available... yes; mandatory

-- without this hack, it says "no" or "yes; optional" and either of those cause the build to fail to KUID issues. The smoking gun I saw were errors about improperly initializing with the wrong type .. i.e. kgid_t groupid = 0; fails because 0 is an integer and not a kgid_t.

@behlendorf - Some additional details in my post/instructions here if it helps:

https://forum.armbian.com/topic/6789-build-zfs-on-rk3328/?do=findComment&comment=53681

Basically, installing spl-dkms fails to compile but the package/build remains on the system, so I modify the generated configure file and manually install and it completes. After that, zfs-dkms builds and installs correctly.. using it successfully/happily with two USB 3.0 8x drive enclosures on top of a hub(!) and it's been more stable than most of the other Linux eSATA/PMP/PCIe/PCI drivers/chipsets I've gone through..

Linux rock64 4.4.126-rockchip-ayufan-220 #1 SMP Tue May 15 22:37:55 UTC 2018 aarch64 aarch64 aarch64 GNU/Linux

aut0 · 2018-07-12T10:49:56Z

I have the same problem on a rock64 board.
However, the headers package is broken as well on the distro, as in @digitalsanity's post

icicimov · 2018-07-30T12:45:10Z

@aut0 spl-dkms and zfs-dkms fail to install for me too on rock64, both failing on ./configure with:

checking kernel source version... 4.4.132-1075-rockchip-ayufan-ga83beded8524
checking kernel file name for module symbols... Module.symvers
checking whether modules can be built... no
configure: error: *** Unable to build an empty module.

Have you found any solution to the broken headers package? I think something is missing but no idea what.

Furthermore, when installed from packages all seems like ends fine:

root@rock64:/tmp# dkms status
spl, 0.7.9: added
zfs, 0.7.9: added

and:

root@rock64:/tmp# dpkg -l | grep dkms        
ii  dkms                                                            2.3-2                                    all          Dynamic Kernel Module Support Framework
ii  spl-dkms                                                        0.7.9-3~bpo9+1                           all          Solaris Porting Layer kernel modules for Linux
ii  zfs-dkms                                                        0.7.9-3~bpo9+1                           all          OpenZFS filesystem kernel modules for Linux

however the modules can not be loaded since they are actually missing from /lib/modules/4.4.132-1075-rockchip-ayufan-ga83beded8524/ directory.

aut0 · 2018-07-30T14:10:43Z

No, I sold the board.

…

On Mon, Jul 30, 2018, 20:45 Igor Cicimov ***@***.***> wrote: @aut0 <https://github.com/aut0> spl-dkms and zfs-dkms fail to install for me too on rock64, both failing on ./configure with: checking kernel source version... 4.4.132-1075-rockchip-ayufan-ga83beded8524 checking kernel file name for module symbols... Module.symvers checking whether modules can be built... no configure: error: *** Unable to build an empty module. Have you found any solution to the broken headers package? I think something is missing but no idea what. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#653 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGx1QMvrP4SL5hNf7wtQWBIV-dqUAobVks5uLv_agaJpZM4PrbBY> .

digitalsanity · 2018-07-30T16:23:30Z

Follow the instructions in the Armbian post above. It shows you how to fix the headers package also. All of those steps will fix the issue for now. Using two 8x raidz2 here on a rock64 and rockpro64.

icicimov · 2018-07-31T11:26:43Z

@digitalsanity thanks, that's what I did already but I get:

root@rock64:/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524# make scripts
  CC      scripts/mod/empty.o
gcc: error: unrecognized command line option '-mgeneral-regs-only'
scripts/Makefile.build:277: recipe for target 'scripts/mod/empty.o' failed
make[2]: *** [scripts/mod/empty.o] Error 1
scripts/Makefile.build:484: recipe for target 'scripts/mod' failed
make[1]: *** [scripts/mod] Error 2
Makefile:582: recipe for target 'scripts' failed
make: *** [scripts] Error 2

That thread was actually the reason I bought this board in the first place since though installing zfs might be doable. Which image do you have installed and what kernel version is this working on?

digitalsanity · 2018-07-31T14:55:01Z

Using the ayufan bionic release--I think you might be missing a build package?

…

On Tue, Jul 31, 2018 at 4:26 AM Igor Cicimov ***@***.***> wrote: @digitalsanity <https://github.com/digitalsanity> thanks, that's what I did already but I get: ***@***.***:/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524# make scripts CC scripts/mod/empty.o gcc: error: unrecognized command line option '-mgeneral-regs-only' scripts/Makefile.build:277: recipe for target 'scripts/mod/empty.o' failed make[2]: *** [scripts/mod/empty.o] Error 1 scripts/Makefile.build:484: recipe for target 'scripts/mod' failed make[1]: *** [scripts/mod] Error 2 Makefile:582: recipe for target 'scripts' failed make: *** [scripts] Error 2 That thread was actually the reason I bought this board in the first place since though installing zfs might be doable. Which image do you have installed and what kernel version is this working on? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#653 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHwNdxKstp6ICfsMX7y7JWBpgT5YJJ05ks5uMD76gaJpZM4PrbBY> .

icicimov · 2018-08-01T10:08:36Z

@digitalsanity first thanks for trying to help. I'm pretty sure I have everything needed installed I double checked the packages need on zfsonlinux site too.

Here is part of the config.log for the ./configure command when trying to build spl from source:

configure:15514: checking kernel source version
configure:15550: result: 4.4.132-1075-rockchip-ayufan-ga83beded8524
configure:15563: checking kernel file name for module symbols
configure:15582: result: Module.symvers
configure:15596: checking whether modules can be built
configure:15619: cp conftest.c build && make modules -C /usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524 EXTRA_CFLAGS=-Werror-implicit-function-declaration   M=/tmp/spl-0.7.9/build 
make[1]: *** [/tmp/spl-0.7.9/build/conftest.o] Error 1
make: *** [_module_/tmp/spl-0.7.9/build] Error 2
configure:15622: $? = 2
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "spl"
| #define PACKAGE_TARNAME "spl"
| #define PACKAGE_VERSION "0.7.9"
| #define PACKAGE_STRING "spl 0.7.9"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define SPL_META_NAME "spl"
| #define SPL_META_VERSION "0.7.9"
| #define SPL_META_RELEASE "1"
| #define SPL_META_LICENSE "GPL"
| #define SPL_META_ALIAS "spl-0.7.9-1"
| #define SPL_META_AUTHOR "OpenZFS on Linux"
| #define PACKAGE "spl"
| #define VERSION "0.7.9"
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| 
| 
| int
| main (void)
| {
| 
|   ;
|   return 0;
| }
| 
configure:15637: result: no
configure:15640: error: *** Unable to build an empty module.

icicimov · 2018-08-01T10:17:21Z

My guess is something related to the arch aarch64:

igorc@rock64:/tmp/spl-0.7.9$ uname -a
Linux rock64 4.4.132-1075-rockchip-ayufan-ga83beded8524 #1 SMP Thu Jul 26 08:22:22 UTC 2018 aarch64 GNU/Linux

at least that's what I think this error tells me:

make: Entering directory '/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524'
  CC [M]  /tmp/spl-0.7.9/build/conftest.o
gcc: error: unrecognized command line option '-mgeneral-regs-only'
gcc: error: unrecognized command line option '-mcmodel=large'
scripts/Makefile.build:283: recipe for target '/tmp/spl-0.7.9/build/conftest.o' failed
make[1]: *** [/tmp/spl-0.7.9/build/conftest.o] Error 1
Makefile:1471: recipe for target '_module_/tmp/spl-0.7.9/build' failed
make: *** [_module_/tmp/spl-0.7.9/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.4.132-1075-rockchip-ayufan-ga83beded8524'

Is the bionic one maybe arm64?

digitalsanity · 2020-02-19T06:19:28Z

There are additional issues for systems using an arm64 kernel and armhf userspace. You will need to follow the armhf/32-bit instructions here to setup cross-compiling:

https://github.com/ayufan-rock64/linux-build/blob/master/recipes/dkms.md

digitalsanity · 2020-02-19T17:48:42Z

There is an issue with arch/arm/include not being packaged with linux header debs for arm64 kernels. arch/arm64/include/asm/opcodes.h tries to include arch/arm/include/asm/opcodes.h, which doesn't exist (because it is an arm64 kernel afterall..)

See more:

ayufan-rock64/linux-build#252 (comment)

behlendorf added the Build Issue label Oct 3, 2017

digitalsanity mentioned this issue Oct 4, 2017

build with DKMS/SPL? ayufan-rock64/linux-build#48

Closed

behlendorf closed this as completed Jun 1, 2018

This was referenced Mar 26, 2019

SPL Build Failure on aarch64 openzfs/zfs#6820

Closed

Can not build or install DKMS modules ayufan-rock64/linux-build#252

Open

ZFS Build Failure on aarch64 openzfs/zfs#8345

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

configure fails to properly "checking whether kuid_t/kgid_t is available..." #653

configure fails to properly "checking whether kuid_t/kgid_t is available..." #653

digitalsanity commented Oct 3, 2017 •

edited

behlendorf commented Oct 3, 2017

digitalsanity commented Oct 3, 2017 •

edited

digitalsanity commented Oct 3, 2017

behlendorf commented Jun 1, 2018

digitalsanity commented Jun 1, 2018 •

edited

aut0 commented Jul 12, 2018

icicimov commented Jul 30, 2018 •

edited

aut0 commented Jul 30, 2018 via email

digitalsanity commented Jul 30, 2018

icicimov commented Jul 31, 2018

digitalsanity commented Jul 31, 2018 via email

icicimov commented Aug 1, 2018

icicimov commented Aug 1, 2018 •

edited

digitalsanity commented Feb 19, 2020

digitalsanity commented Feb 19, 2020

configure fails to properly "checking whether kuid_t/kgid_t is available..." #653

configure fails to properly "checking whether kuid_t/kgid_t is available..." #653

Comments

digitalsanity commented Oct 3, 2017 • edited

behlendorf commented Oct 3, 2017

digitalsanity commented Oct 3, 2017 • edited

digitalsanity commented Oct 3, 2017

behlendorf commented Jun 1, 2018

digitalsanity commented Jun 1, 2018 • edited

aut0 commented Jul 12, 2018

icicimov commented Jul 30, 2018 • edited

aut0 commented Jul 30, 2018 via email

digitalsanity commented Jul 30, 2018

icicimov commented Jul 31, 2018

digitalsanity commented Jul 31, 2018 via email

icicimov commented Aug 1, 2018

icicimov commented Aug 1, 2018 • edited

digitalsanity commented Feb 19, 2020

digitalsanity commented Feb 19, 2020

digitalsanity commented Oct 3, 2017 •

edited

digitalsanity commented Oct 3, 2017 •

edited

digitalsanity commented Jun 1, 2018 •

edited

icicimov commented Jul 30, 2018 •

edited

icicimov commented Aug 1, 2018 •

edited