| Summary: | Disabling CONFIG_COMPAT_32BIT_TIME breaks multilib systems | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michelangelo Scopelliti <kernelpanic> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED CANTFIX | ||
| Severity: | normal | CC: | ionen, janpieter.sollie, jstein, mgorny, multilib+disabled, sam, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=801313 https://bugs.gentoo.org/show_bug.cgi?id=801418 https://bugs.gentoo.org/show_bug.cgi?id=907778 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
build log
kernel configs |
||
|
Description
Michelangelo Scopelliti
2020-08-06 16:30:10 UTC
Please post a build log. Created attachment 654108 [details]
build log
attached.
OK, I think I found the cause of my problem. A few days ago I switched to kernel 5.8.0 and unset CONFIG_COMPAT_32BIT_TIME. This caused the issue. Setting it to "y" again fixed the mesa issue. How I got it? simple; the problem was llvm? OK, let's rebuild it. Rebuilding fails with a "The futex facility returned an unexpected error"? OK, let's rebuild the whole system. Again, the futex error shows up (at least) for llvm, wine-vanilla, icu and so on. A little bit of digging and... So, long story short, maybe a check on CONFIG_COMPAT_32BIT_TIME on multiarch systems could help (at least on icu and llvm). What do you think? (In reply to Michelangelo Scopelliti from comment #3) > So, long story short, maybe a check on CONFIG_COMPAT_32BIT_TIME on multiarch > systems could help (at least on icu and llvm). Something for multilib@ and toolchain@ I think. Also, build.log does not look complete as I don't see actual USE-flags being used when mesa is built. Can you upload full build.log? Comparing to my system where things seem to work I see a few differences that may or may not matter: 1. I use ld.bfd, failed build.log has ld.gold 2. I use pkg-config, but.log uses pkgconf 3. My log claims to detect llvm-config, build.log's don't: good: """ llvm-config found: YES (/usr/lib/llvm/10/bin/i686-pc-linux-gnu-llvm-config) 10.0.1 """ bad: """ WARNING: Ignoring LLVM CMake dependency because dynamic was requested llvm-config found: NO need '>= 3.9.0' Run-time dependency LLVM found: NO (tried cmake and config-tool) """ But it's probably due to USE flags difference. Would be nice to find exact command that changes output based on CONFIG_COMPAT_32BIT_TIME to debug why failure happens. Then we can decide there appropriate fix belongs. (In reply to Sergei Trofimovich from comment #5) Sorry for my delay, in the last week I had a few issues with my internet connection -- still having, but now I can answer. > Also, build.log does not look complete as I don't see actual USE-flags being > used when mesa is built. Can you upload full build.log? The build log is full -- I mean, it is the build log I find in /var/log/portage/build/media-libs/. about the USE-flags, emerge -pqv mesa (now, new version, same issue) [ebuild R ] media-libs/mesa-20.2.0_rc4 USE="X classic dri3 egl gallium gbm gles2 (libglvnd) llvm vulkan zstd -d3d9 -debug -gles1 -lm-sensors -opencl -osmesa (-selinux) -test -unwind -vaapi -valgrind -vdpau -vulkan-overlay -wayland -xa -xvmc -zink" ABI_X86="32 (64) (-x32)" VIDEO_CARDS="i965 intel iris (-freedreno) -i915 (-lima) -nouveau (-panfrost) -r100 -r200 -r300 -r600 -radeon -radeonsi (-v3d) (-vc4) -virgl (-vivante) -vmware" > > Comparing to my system where things seem to work I see a few differences > that may or may not matter: > > 1. I use ld.bfd, failed build.log has ld.gold I thought that could be an issue too. So I rebuilt my system with bfd as default; the issue remains. > 2. I use pkg-config, but.log uses pkgconf In the past I had issue with gold, but pkgconf reads the same files as pkg-config, with the same output, and without glib dependency. I don't thik it' the responsible here > 3. My log claims to detect llvm-config, build.log's don't: $ ls -l `which llvm-config` lrwxrwxrwx 1 root root 31 25 ago 19.32 /usr/lib/llvm/10/bin/llvm-config -> x86_64-pc-linux-gnu-llvm-config > > good: > > """ > llvm-config found: YES (/usr/lib/llvm/10/bin/i686-pc-linux-gnu-llvm-config) > 10.0.1 > """ > > bad: > > """ > WARNING: Ignoring LLVM CMake dependency because dynamic was requested > llvm-config found: NO need '>= 3.9.0' > Run-time dependency LLVM found: NO (tried cmake and config-tool) > """ > > But it's probably due to USE flags difference. Well, isn't that the issue? > > Would be nice to find exact command that changes output based on > CONFIG_COMPAT_32BIT_TIME to debug why failure happens. Then we can decide > there appropriate fix belongs. As a counte- proof: I've just compiled a kernel with CONFIG_COMPAT_32BIT_TIME unset, and I had the same error. No issues at all (both with gold and bfd) if CONFIG_COMPAT_32BIT_TIME is set. I will upload both kernel configurations. Created attachment 659018 [details]
kernel configs
besides the date, the only difference was setting CONFIG_COMPAT_32BIT_TIME (via nconfig)
(In reply to Michelangelo Scopelliti from comment #6) > (In reply to Sergei Trofimovich from comment #5) > > Sorry for my delay, in the last week I had a few issues with my internet > connection -- still having, but now I can answer. > > > Also, build.log does not look complete as I don't see actual USE-flags being > > used when mesa is built. Can you upload full build.log? > > The build log is full -- I mean, it is the build log I find in > /var/log/portage/build/media-libs/. Oh, yeah. Build.log looks fine. Don't know where I looked. My apologies. > > 2. I use pkg-config, but.log uses pkgconf > > In the past I had issue with gold, but pkgconf reads the same files as > pkg-config, with the same output, and without glib dependency. I don't thik > it' the responsible here It might not be it but pkgconf is known to deviate slightly from pkg-config (like i bug #703932). But given you can consistently fil the error on and off with kernel option points at the build system problem. > > 3. My log claims to detect llvm-config, build.log's don't: > > $ ls -l `which llvm-config` > lrwxrwxrwx 1 root root 31 25 ago 19.32 /usr/lib/llvm/10/bin/llvm-config -> > x86_64-pc-linux-gnu-llvm-config > > > > > good: > > > > """ > > llvm-config found: YES (/usr/lib/llvm/10/bin/i686-pc-linux-gnu-llvm-config) > > 10.0.1 > > """ > > > > bad: > > > > """ > > WARNING: Ignoring LLVM CMake dependency because dynamic was requested > > llvm-config found: NO need '>= 3.9.0' > > Run-time dependency LLVM found: NO (tried cmake and config-tool) > > """ > > > > But it's probably due to USE flags difference. > > Well, isn't that the issue? Maybe. Depends on whether you have or don't have /usr/lib/llvm/10/bin/i686-pc-linux-gnu-llvm-config file. Not clear if the file is missing onr 'stat' on it is somehow broken. > > Would be nice to find exact command that changes output based on > > CONFIG_COMPAT_32BIT_TIME to debug why failure happens. Then we can decide > > there appropriate fix belongs. > > As a counte- proof: I've just compiled a kernel with > CONFIG_COMPAT_32BIT_TIME unset, and I had the same error. No issues at all > (both with gold and bfd) if CONFIG_COMPAT_32BIT_TIME is set. I will upload > both kernel configurations. Great you have found a trigger! Now we'll need to find what is broken by it. Given that by default 'time_t' is still 32-bit on i686-glibc I suspect glibc still uses 32-bit syscalls. Specifically kernel says: arch/Kconfig:config COMPAT_32BIT_TIME arch/Kconfig- bool "Provide system calls for 32-bit time_t" arch/Kconfig- default !64BIT || COMPAT arch/Kconfig- help arch/Kconfig- This enables 32 bit time_t support in addition to 64 bit time_t support. arch/Kconfig- This is relevant on all 32-bit architectures, and 64-bit architectures arch/Kconfig- as part of compat syscall handling. and seems to guard the presence of the following syscalls: - a bunch of v4l2 IOCTLs like VIDIOC_DQEVENT_TIME32 - io_pgetevents_time32, io_getevents_time32, io_pgetevents - pselect6_time32, ppoll_time32 - timerfd_settime32 - utime32 - semtimedop - futex - sched_rr_get_interval_time32, rt_sigtimedwait_time32, - hrtimer IOCTLs - clock_settime32, timer_gettime32, clock_nanosleep_time32, time32 - recvmmsg_time32 I suspect things like futex and time32 break a lot of 32-bit programs for you (or 64-bit programs with 32-bit interfaces, unlikely). They just don't get called at build time most of time time. *** Bug 742257 has been marked as a duplicate of this bug. *** (In reply to Michelangelo Scopelliti from comment #7) > Created attachment 659018 [details] > kernel configs > > besides the date, the only difference was setting CONFIG_COMPAT_32BIT_TIME > (via nconfig) Are you planning to follow up? (In reply to Matt Turner from comment #10) > (In reply to Michelangelo Scopelliti from comment #7) > > Created attachment 659018 [details] > > kernel configs > > > > besides the date, the only difference was setting CONFIG_COMPAT_32BIT_TIME > > (via nconfig) > > Are you planning to follow up? I don't know how. It seems to me that multiarch system could benefit from something like inherit linux-info ... CONFIG_CHECK="COMPAT_32BIT_TIME" at least for mesa, icu, llvm and wine; what else can I add? (In reply to Michelangelo Scopelliti from comment #11) > (In reply to Matt Turner from comment #10) > > (In reply to Michelangelo Scopelliti from comment #7) > > > Created attachment 659018 [details] > > > kernel configs > > > > > > besides the date, the only difference was setting CONFIG_COMPAT_32BIT_TIME > > > (via nconfig) > > > > Are you planning to follow up? > > I don't know how. It seems to me that multiarch system could benefit from > something like > > inherit linux-info > ... > CONFIG_CHECK="COMPAT_32BIT_TIME" > > at least for mesa, icu, llvm and wine; what else can I add? Sorry, I thought Sergei had requested some information from you. I misread, my fault. https://bugs.gentoo.org/801313#c11 makes a good case to add the check to glibc itself. (In reply to Sergei Trofimovich from comment #13) > https://bugs.gentoo.org/801313#c11 makes a good case to add the check to > glibc itself. However, it probably won't be a good enough solution. After all, people don't usually rebuild glibc after upgrading the kernel. toolchain, not sure if you want to resolve this, or resolve as invalid like the reference bug in comment #13 Unfortunately, I think there is really no good place to put a kernel config check for this option. I updated the AMD64 handbook to indicate that the option is required for multilib systems. I think that's about the best we can do. |
