У меня на https://packages.altlinux.org/ru/tasks/396203/ не собирается модуль ядра на aarch64. Локально всё собирается. При конфигурации сборки выполняются 2 теста: Тест1: #include <linux/acpi.h> void conftest_acpi_walk_namespace(void) { acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL, NULL); } Тест2: #include <linux/acpi.h> void conftest_acpi_walk_namespace(void) { acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL); } Локально успешно собирается Тест1 и дальше идёт сборка модуля. В сборочнице не собираются оба, из-за чего в код добавляют: #error acpi_walk_namespace() conftest failed! , с чем сборка по ссылке падает.
> Локально всё собирается. На aarch64 проверял.
попробуй тесты запускать через vm-run
А где ссылка на таск, в котором видно, как именно не собирается тест? Иначе нужно обращаться к ясновидящим, не знаю что ещё посоветовать.
(Ответ для Gleb F-Malinovskiy на комментарий #3) > А где ссылка на таск, в котором видно, как именно не собирается тест? https://packages.altlinux.org/ru/tasks/396203/ Просто так вывести нельзя, т.к. вывод используется в качестве результата. Сохранил вывод для каждого теста в файлы conftest??????.c.txt . Искать по слову acpi_walk_namespace.
Ошибся, переделал. Ошибки сборки конкретного теста в файле conftest*.c_.txt
(In reply to Sergey V Turchin from comment #5) > Ошибся, переделал. Ошибки сборки конкретного теста в файле conftest*.c_.txt Так, и где на этот файл посмотреть? Можно, пожалуйста, прислать готовый багрепорт а не заставлять других делать багрепорт за вас? Я не буду этого делать, буду ждать когда будет багрепорт.
(Ответ для Gleb F-Malinovskiy на комментарий #6) > (In reply to Sergey V Turchin from comment #5) > > Ошибся, переделал. Ошибки сборки конкретного теста в файле conftest*.c_.txt > Так, и где на этот файл посмотреть? Там, где воспроизводится, т.е. на сборочнице. > Можно, пожалуйста, прислать готовый багрепорт а не заставлять других делать > багрепорт за вас? Дайте доступ на сборочницу -- сделаю. > Я не буду этого делать, буду ждать когда будет багрепорт. А кто будет из тех, у кого есть доступ к багу?
Оказалось, я не те kernel-source локально собирал. У меня воспроизвелось.
In file included from /usr/src/linux-6.12.55-6.12/arch/arm64/include/asm/acpi.h:13, from /usr/src/linux-6.12.55-6.12/include/acpi/acpi_io.h:7, from /usr/src/linux-6.12.55-6.12/include/linux/acpi.h:39, from conftest24148.c:13: /usr/src/linux-6.12.55-6.12/include/linux/efi.h: In function 'efi_get_secureboot_mode': /usr/src/linux-6.12.55-6.12/include/linux/efi.h:1155:26: error: passing argument 1 of 'get_var' from incompatible pointer type [-Wincompatible-pointer-types] 1155 | status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, | ^~~~~~~~~~~~~ | | | unsigned int *
/usr/src/linux-6.12.55-6.12/include/linux/efi.h static inline enum efi_secureboot_mode efi_get_secureboot_mode(efi_get_variable_t *get_var) { u8 secboot, setupmode = 0; efi_status_t status; unsigned long size; size = sizeof(secboot); status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, NULL, &size, &secboot);
Этот баг -- явный пример попытки переложить со своей головы на чужую и желание не решать и не разбираться в проблеме. "Сборочница виновата, что у меня неизвестно какой код, который я вам не покажу не компилируется с диагностикой, которую я вам тоже не покажу" это не багрепорт, а пустая сознательная трата времени других людей. Не делайте так больше, пожалуйста.
(Ответ для Gleb F-Malinovskiy на комментарий #11) > "Сборочница виновата, что у меня неизвестно какой код, который я вам не > покажу не компилируется с диагностикой, которую я вам тоже не покажу Я полагал, что у меня не воспроизводится. Я дал вам всё. У меня нет возможности залезть на сборочницу.
А по существу то что? Я не понимаю, в чём проблема.
По существу -- баг если и есть, то не в сборочнице.
(Ответ для Gleb F-Malinovskiy на комментарий #11) > Не делайте так больше, пожалуйста. Накосячил, извиняюсь. Полагал, что больше ничего не в силах сделать. Я ж даже пропатчил специально, чтоб дебаг в файлы сохранялся.
(Ответ для Gleb F-Malinovskiy на комментарий #14) > По существу -- баг если и есть, то не в сборочнице. Я не против, что не в сборочнице. Как мне определить, где? Или хоть что-то определить?
Флаги cc -O2 -D__KERNEL__ -DKBUILD_BASENAME="#conftest46990" -DKBUILD_MODNAME="#conftest46990" -nostdinc -isystem /usr/lib64/gcc/aarch64-alt-linux/14/include -Wno-implicit-function-declaration -Wno-strict-prototypes -I/usr/src/linux-6.12.55-6.12/include/asm-arm64/mach-default -I/usr/src/linux-6.12.55-6.12/arch/arm64/include/asm/mach-default -include /usr/src/linux-6.12.55-6.12/include/generated/autoconf.h -I/usr/src/linux-6.12.55-6.12/include -I/usr/src/linux-6.12.55-6.12/include/uapi -I/usr/src/linux-6.12.55-6.12/include/xen -I/usr/src/linux-6.12.55-6.12/include/generated/uapi -I/usr/src/linux-6.12.55-6.12/arch/arm64/include -I/usr/src/linux-6.12.55-6.12/arch/arm64/include/uapi -I/usr/src/linux-6.12.55-6.12/arch/arm64/include/generated -I/usr/src/linux-6.12.55-6.12/arch/arm64/include/generated/uapi -std=gnu17 -I/home/zerg/RPM/BUILD/kernel-modules-nvidia-6.12-580.82.09/kernel-source-nvidia-47025602/common/inc -I/home/zerg/RPM/BUILD/kernel-modules-nvidia-6.12-580.82.09/kernel-source-nvidia-47025602 -Wall -MD -Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"470.256.02\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mstrict-align -mgeneral-regs-only -march=armv8-a -DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 -DNV_KERNEL_INTERFACE_LAYER -I/home/zerg/RPM/BUILD/kernel-modules-nvidia-6.12-580.82.09/kernel-source-nvidia-47025602/common/inc -I/home/zerg/RPM/BUILD/kernel-modules-nvidia-6.12-580.82.09/kernel-source-nvidia-47025602 -Wall -MD -Wno-cast-qual -Wno-error -Wno-format-extra-args -D__KERNEL__ -DMODULE -DNVRM -DNV_VERSION_STRING=\"470.256.02\" -Wno-unused-function -Wuninitialized -fno-strict-aliasing -mstrict-align -mgeneral-regs-only -march=armv8-a -DNV_UVM_ENABLE -Werror=undef -DNV_SPECTRE_V2=0 -DNV_KERNEL_INTERFACE_LAYER -fno-stack-clash-protection -fcf-protection=none -fno-pie
Тогда ядро
(In reply to Sergey V Turchin from comment #0) > Тест1: > #include <linux/acpi.h> > void conftest_acpi_walk_namespace(void) { > acpi_walk_namespace(0, NULL, 0, NULL, NULL, NULL, NULL); > } В 6.12 у acpi_walk_namespace 7 аргументов. Определение этой функции не менялось минимум с 2014. Функция определена в nsxfeval.c, который безусловно входит в код acpi, при этом acpi включен при включенном CONFIG_ACPI, который у нас включен на всех архитектурах. Sisyphus/kernel-image-6.12-6.12.55-alt1.aarch64:CONFIG_ACPI=y Sisyphus/kernel-image-6.12-6.12.55-alt1.i586:CONFIG_ACPI=y Sisyphus/kernel-image-6.12-6.12.55-alt1.x86_64:CONFIG_ACPI=y > Локально успешно собирается Тест1 и дальше идёт сборка модуля. > В сборочнице не собираются оба, из-за чего в код добавляют: > #error acpi_walk_namespace() conftest failed! > , с чем сборка по ссылке падает. Какая ошибка при сборке Тест1?
Чтоб это увидеть, может будет достаточно добавить V=1 в make modules (может нет). Я попробовал собрать задание 396203 - сборка не начинается, видимо, ему не хватает каких-то подпакетов. E: Couldn't find package kernel-source-nvidia-5808209 А там только nvidia_glx_src_470.256.02.git=470.256-alt258
(Ответ для Vitaly Chikunov на комментарий #20) > Чтоб это увидеть, может будет достаточно добавить V=1 в make modules (может > нет) Не. Там тесты для настройки сборки. У них вывод перенаправлен. Пришлось https://git.altlinux.org/tasks/396203/gears/70/git?p=git;a=blob;f=alt-conftest-output.patch > . Я попробовал собрать задание 396203 - сборка не начинается, видимо, > ему не хватает каких-то подпакетов. > E: Couldn't find package kernel-source-nvidia-5808209 kernel-modules-nvidia устарел. Ща передобавлю и запущу.
(Ответ для Sergey V Turchin на комментарий #9) > /usr/src/linux-6.12.55-6.12/include/linux/efi.h:1155:26: error: passing > argument 1 of 'get_var' from incompatible pointer type > [-Wincompatible-pointer-types] > 1155 | status = get_var(L"SecureBoot", &EFI_GLOBAL_VARIABLE_GUID, > NULL, &size, > | ^~~~~~~~~~~~~ > | | > | unsigned int * Если я добавляю флаг компиляции -fshort-wchar , то всё собирается. Т.к. он используется только в коде конфигурации сборки, то начну его использовать.
Это новый баг? Видимо, -fshort-wchar теряется при сборке вашего кода. Вопрос только почему.
(Ответ для Vitaly Chikunov на комментарий #23) > Это новый баг? Нет, всё то же. > Видимо, -fshort-wchar теряется при сборке вашего кода. Тогда он может теряться и при сборке основного кода, а я полагаю, что его использовать вообще стрёмно. > Вопрос только почему. Что-то с опциями сборки поменялось, но не смог найти.
Ядро использует -fshort-wchar на всех архитектурах (это можно увидеть если собирать ядро с V=1). https://github.com/torvalds/linux/blob/master/Makefile#L588
(Ответ для Vitaly Chikunov на комментарий #25) > Ядро использует -fshort-wchar на всех архитектурах Ок, спасибо! Теперь хотя бы ясно, куда копать.
