[ ПОЧИНИЛИ ] Обновление ccache сломало компиляцию recovery TWRP

Приветствую.

После обновления ccache до 3.7.8-1 компиляция recovery TWRP на исходниках omni ломается в самом начале с ошибкой, приведенной ниже. Причём, я даже не понимал, с какой стороны ветер дует (ведь накануне на том же самом конфиге это же TWRP-recovery собиралось без проблем), пока не увидел в логе ошибки эту запись:

ccache: error: Internal error in format

Сдаунгрейдив ccache до предыдущей версии 3.7.7-1, компиляция сразу прошла успешно и образ recovery собрался. Ошибку эту я вижу впервые за 3 года сборки TWRP. Всякие были, но никогда не связанные с ccache. Итак, код с ошибкой ниже, и вопрос - как исправить, и надо ли исправлять:

[  0% 108/11007] host C: version_polic...system/sepolicy/tools/version_policy.c
FAILED: /home/yurius/omni_8/out/host/linux-x86/obj/EXECUTABLES/version_policy_intermediates/version_policy.o
/bin/bash -c "PWD=/proc/self/cwd /usr/bin/ccache prebuilts/clang/host/linux-x86/clang-4053586/bin/clang   	-I system/sepolicy/tools -I /home/yurius/omni_8/out/host/linux-x86/obj/EXECUTABLES/version_policy_intermediates -I /home/yurius/omni_8/out/host/linux-x86/gen/EXECUTABLES/version_policy_intermediates -I libnativehelper/include_deprecated \$(cat /home/yurius/omni_8/out/host/linux-x86/obj/EXECUTABLES/version_policy_intermediates/import_includes)  -I system/core/include -I system/media/audio/include -I hardware/libhardware/include -I hardware/libhardware_legacy/include -I libnativehelper/include -I frameworks/native/include -I frameworks/native/opengl/include -I frameworks/av/include  -c  -fno-exceptions -Wno-multichar -Wa,--noexecstack -fPIC -no-canonical-prefixes -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fstack-protector -D__STDC_FORMAT_MACROS -D__STDC_CONSTANT_MACROS -O2 -g -fno-strict-aliasing --gcc-toolchain=prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.8 --sysroot prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.8/sysroot -fstack-protector-strong -m64 -DANDROID -fmessage-length=0 -W -Wall -Wno-unused -Winit-self -Wpointer-arith -DNDEBUG -UDEBUG -fdebug-prefix-map=/proc/self/cwd= -D__compiler_offsetof=__builtin_offsetof -Werror=int-conversion -Wno-reserved-id-macro -Wno-format-pedantic -Wno-unused-command-line-argument -fcolor-diagnostics -Wno-expansion-to-defined -fdebug-prefix-map=\$PWD/=   -target x86_64-linux-gnu -Bprebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.8/x86_64-linux/bin   -std=gnu99  -Wall -Werror -fPIE -DANDROID_STRICT   -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast -Werror=address-of-temporary -Werror=return-type -MD -MF /home/yurius/omni_8/out/host/linux-x86/obj/EXECUTABLES/version_policy_intermediates/version_policy.d -o /home/yurius/omni_8/out/host/linux-x86/obj/EXECUTABLES/version_policy_intermediates/version_policy.o system/sepolicy/tools/version_policy.c"

ccache: error: Internal error in format

[  1% 112/11007] Check module type: /h...S/libbacktrace_intermediates/link_type
ninja: build stopped: subcommand failed.
07:40:47 ninja failed with: exit status 1

#### failed to build some targets (29 seconds) ####
А кеш почистить перед сборкой не пробовали?
ccache -C
от того пользователя от которого сборку запускаете
vs220
А кеш почистить перед сборкой не пробовали?
ccache -C

Это в смысле удалить всё содержимое папки ~/.ccache? Если да, то удалял вручную всё оттуда - разумеется, никакого эффекта, та же ошибка была. Более того, кэш очень нужен, в этом же собственно и его смысл - компиляция при наличии кэша в .ccache сокращается иногда раза в 2-3.
Лучше командой удалить. Просто не всегда старый кеш с новой версией может работать, он заново создастся.
vs220
Лучше командой удалить

Удалил командой, перезагрузился, начал компиляцию с нуля (make clean) - ожидаемо не помогло, та же ошибка.
И вы еще со старой версией glibc2.15-4.8 собираете, может тоже несовместимость
Там баг исправляли и вроде добавили version может это повлияло
https://bugs.archlinux.org/task/63933?project=0&order=id&sort=desc&status%5B0%5D=closed&string=ccache

Надо
indeviral звать мож он разберется
vs220
вы еще со старой версией glibc2.15-4.8 собираете, может тоже несовместимость

Ну это та версия, которая в исходниках omni_8 находится (/home/yurius/omni_8/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.8/) и с ней по умолчанию собирается.

yurius@yurius:~/omni_8$ ls -l /home/yurius/omni_8/prebuilts/gcc/linux-x86/host/x86_64-linux-glibc2.15-4.8/
total 118784
-rwxrwxrwx 1 yurius users     0 Feb 21  2019 MODULE_LICENSE_GPL
-rwxrwxrwx 1 yurius users 18002 Feb 21  2019 NOTICE
-rwxrwxrwx 1 yurius users  8374 Feb 21  2019 PACKAGE_SOURCES
-rwxrwxrwx 1 yurius users  1317 Feb 21  2019 TOOLCHAIN_SOURCES
drwxr-xr-x 2 yurius users  4096 Dec 21 16:45 bin
-rwxrwxrwx 1 yurius users 48772 Feb 21  2019 build-precise-multilib-toolchain.sh
drwxr-xr-x 4 yurius users  4096 Dec 21 16:45 include
drwxr-xr-x 4 yurius users  4096 Dec 21 16:45 lib
drwxr-xr-x 2 yurius users  4096 Dec 21 16:45 lib64
drwxr-xr-x 3 yurius users  4096 Dec 21 16:45 libexec
drwxr-xr-x 3 yurius users  4096 Dec 21 16:45 sysroot
drwxr-xr-x 3 yurius users  4096 Dec 21 16:45 toolchain-patches
drwxr-xr-x 7 yurius users  4096 Dec 21 16:45 x86_64-linux

Как собирать с более высокой версией - не знаю. В системе (pacman -Qi) установлена 2.31. Кстати, 2.15 присутствует во ВСЕХ исходниках - с 6 по 9 - так что не исключено, что именно она нужна для сборки, и другая просто не подойдёт. Так же, как не годятся для сборки python3 (только 2 нужен) и java выше 8-9 версий.
В версии 3.7.9, прилетевшей час назад, всё починили, образы собираются, вопрос закрыт.
 
Зарегистрироваться или войдите чтобы оставить сообщение.