Bug 56331

> Локально всё собирается.
На 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 на всех архитектурах
Ок, спасибо! Теперь хотя бы ясно, куда копать.