makekeys: failed to find small enough hash! Try increasing KTNUM in makekeys.c make[1]: *** [Makefile:1422: ks_tables.h] Error 1 make[1]: Leaving directory '/var/tmp/portage/x11-libs/libX11-1.6.5/work/libX11-1.6.5-abi_x86_32.x86/src' ----------------------------------------------------------------- This is an unstable amd64 chroot image (named 13.0-libressl-abi32+64_20170419-212006) at a hardened host acting as a tinderbox. ----------------------------------------------------------------- gcc-config -l: [1] x86_64-pc-linux-gnu-6.3.0 * Available Python interpreters, in order of preference: [1] python3.4 [2] python2.7 (fallback)
Created attachment 470478 [details] emerge-info.txt
Created attachment 470480 [details] config.log.tbz2
Created attachment 470482 [details] emerge-history.txt
Created attachment 470484 [details] environment
Created attachment 470486 [details] etc.portage.tbz2
Created attachment 470488 [details] temp.tbz2
Created attachment 470490 [details] x11-libs:libX11-1.6.5:20170420-040115.log
seems to be an ABI=32 problem, occurred today at tinderbox image 13.0-desktop-plasma_abi32+64_20170716-132501 too
and today again at 17.0-desktop-gnome-systemd_libressl-abi32+64_20180415-103854 FWIW the make.conf: USE=" 16bit-indices a52 acl activefilter -adobe-cff a-like-o aqbanking -attica bibutils cdrom chromecast cinder debug-malloc enigma fits -freewnn -glide google handbook -hdaps icarus irda -lxml pbkdf2 qmail-spp quote system-jpeg -telepathy usrmerge utmp visio warmstarts xetex xfce zemberek zstd ssp -cdinstall -oci8 -pax_kernel -valgrind -symlink "
This seems to be an ABI_X86="32 64" problem b/c it doesn't occur at other images then those,
This is likely a problem with large file support in sandbox. I get the same errors on 3Tb XFS filesystem: ../src/util/makekeys /usr/include/X11/keysymdef.h /usr/include/X11/XF86keysym.h /usr/include/X11/Sunkeysym.h /usr/include/X11/DECkeysym.h /usr/include/X11/HPkeysym.h > ks_tables_h couldn't open /usr/include/X11/keysymdef.h couldn't open /usr/include/X11/XF86keysym.h couldn't open /usr/include/X11/Sunkeysym.h couldn't open /usr/include/X11/DECkeysym.h couldn't open /usr/include/X11/HPkeysym.h makekeys: failed to find small enough hash! Try increasing KTNUM in makekeys.c FEATURES="-sandbox -usersandbox" workarounds this problem for me.
(In reply to Alexander Tsoy from comment #11) > This is likely a problem with large file support in sandbox. Interesting, here I do use two 1.6 TB file systems (LVM) with BTRFS for the tinderbox.
IIRC btrfs does not reuse inode numbers (if inode_cache is off), so even on a filesystem smaller than 2Tb they could reach 64-bit values.
(In reply to Alexander Tsoy from comment #11) > This is likely a problem with large file support in sandbox. Or more likely this is because "makekeys" lacks lfs support. And when sandbox is disabled, it silently fail to open files (due to bug 681790 ?). I'll try to debug this later.
(In reply to Alexander Tsoy from comment #14) > Or more likely this is because "makekeys" lacks lfs support. And when > sandbox is disabled, it silently fail to open files (due to bug 681790 ?). makekeys is indeed compiled without large file support, however it's somehow works without sandbox. By "works" I mean that it actually successfully opens files with inode numbers > 2^32 using fopen(): # ls -1i /usr/include/X11/keysymdef.h /usr/include/X11/XF86keysym.h /usr/include/X11/Sunkeysym.h /usr/include/X11/DECkeysym.h /usr/include/X11/HPkeysym.h 4603511856 /usr/include/X11/DECkeysym.h 4603511855 /usr/include/X11/HPkeysym.h 4603511852 /usr/include/X11/Sunkeysym.h 4603511847 /usr/include/X11/XF86keysym.h 4603511854 /usr/include/X11/keysymdef.h Adding append-lfs-flags to ebuild fixes this issue. So I think this is a duplicate of bug 550502
(In reply to Alexander Tsoy from comment #15) > (In reply to Alexander Tsoy from comment #14) > > Or more likely this is because "makekeys" lacks lfs support. And when > > sandbox is disabled, it silently fail to open files (due to bug 681790 ?). > makekeys is indeed compiled without large file support, however it's somehow > works without sandbox. By "works" I mean that it actually successfully opens > files with inode numbers > 2^32 using fopen(): > > # ls -1i /usr/include/X11/keysymdef.h /usr/include/X11/XF86keysym.h > /usr/include/X11/Sunkeysym.h /usr/include/X11/DECkeysym.h > /usr/include/X11/HPkeysym.h > 4603511856 /usr/include/X11/DECkeysym.h > 4603511855 /usr/include/X11/HPkeysym.h > 4603511852 /usr/include/X11/Sunkeysym.h > 4603511847 /usr/include/X11/XF86keysym.h > 4603511854 /usr/include/X11/keysymdef.h > > > Adding append-lfs-flags to ebuild fixes this issue. So I think this is a > duplicate of bug 550502 Thanks for debugging! Anyone want to give https://gitlab.freedesktop.org/xorg/lib/libx11/merge_requests/14 a try?
(In reply to Matt Turner from comment #16) > Thanks for debugging! Anyone want to give > https://gitlab.freedesktop.org/xorg/lib/libx11/merge_requests/14 a try? Thanks! It works for me. I've also applied the following patch: https://gitlab.freedesktop.org/xorg/lib/libx11/commit/a121b7b0c210efe10bf93453b29050282324c906
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6e63e33be6eb1f152b27c00a81494e85b3152709 commit 6e63e33be6eb1f152b27c00a81494e85b3152709 Author: Matt Turner <mattst88@gentoo.org> AuthorDate: 2019-06-17 14:54:52 +0000 Commit: Matt Turner <mattst88@gentoo.org> CommitDate: 2019-06-17 15:18:51 +0000 x11-libs/libX11: Version bump to 1.6.8 Closes: https://bugs.gentoo.org/299654 Closes: https://bugs.gentoo.org/550502 Closes: https://bugs.gentoo.org/616140 Signed-off-by: Matt Turner <mattst88@gentoo.org> x11-libs/libX11/Manifest | 1 + x11-libs/libX11/libX11-1.6.8.ebuild | 28 ++++++++++++++++++++++++++++ 2 files changed, 29 insertions(+)
