LINUX.ORG.RU

Ошибки при сборке ядра

 , ,


0

1

всем добра. Собираю ядро для MI MIX 3 5G, по инструкции с репозитория (https://github.com/MiCode/Xiaomi_Kernel_OpenSource/wiki/How-to-compile-kernel-standalone). Однако не все так просто, в коде ядра куча варнингов, которые вылезают в виде ошибок. Вот пример одного из них:

make[1]: Entering directory '/home/fck/Mi_Kernel/andromeda-p-oss/out'
  CHK     include/config/kernel.release
  Using .. as source for kernel
  GEN     ./Makefile
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CHK     include/generated/bounds.h
  CHK     include/generated/timeconst.h
  CHK     include/generated/asm-offsets.h
  CALL    ../scripts/checksyscalls.sh
  CHK     scripts/mod/devicetable-offsets.h
  CHK     include/generated/compile.h
  CC      arch/arm64/mm/fault.o
../arch/arm64/mm/fault.c: In function 'mem_abort_decode':
../arch/arm64/mm/fault.c:127:2: warning: format '%lu' expects argument of type 'long unsigned int', but argument 2 has type 'unsigned int' [-Wformat=]
error, forbidden warning: fault.c:127
../scripts/Makefile.build:363: recipe for target 'arch/arm64/mm/fault.o' failed
make[2]: *** [arch/arm64/mm/fault.o] Error 1
/home/fck/Mi_Kernel/andromeda-p-oss/Makefile:1135: recipe for target 'arch/arm64/mm' failed
make[1]: *** [arch/arm64/mm] Error 2
make[1]: Leaving directory '/home/fck/Mi_Kernel/andromeda-p-oss/out'
Makefile:146: recipe for target 'sub-make' failed
make: *** [sub-make] Error 2

Я понимаю, что можно упороться и поустранять их все. Но их там сотни, если не тысячи. Как можно задушить их? спасибо ;)

Ответ на: комментарий от Redfern89

А «…_defconfig» для какой архитектуры? Скорее всего, скачал для 32 битной архитектуры, но пытаешься собрать для 64 бит. В приведенной тобой ошибке ругается на то, что пытаешся отформатировать 32 битный аргумент как 64-битный

anonymous
()
Ответ на: комментарий от Redfern89

Ты убедись, что именно он вызывается. Заставь make печатать в консоль полную команду, чтобы было видно путь до компилятора. Ну или в списке процессов посмотри во время компиляции.

ox55ff ★★★★★
()
Ответ на: комментарий от ox55ff

Заставь make печатать в консоль полную команду

запустил с V=1, все имеет примерно такой вывод

python ../scripts/gcc-wrapper.py /home/fck/Mi_Kernel/andromeda-p-oss/toolchain/bin/aarch64-linux-android-gcc -Wp,-MD,kernel/trace/.bpf_trace.o.d  -nostdinc -isystem /home/fck/Mi_Kernel/andromeda-p-oss/toolchain/bin/../lib/gcc/aarch64-linux-android/4.9.x/include -I../arch/arm64/include -I./arch/arm64/include/generated  -I../include -I./include -I../arch/arm64/include/uapi -I./arch/arm64/include/generated/uapi -I../include/uapi -I./include/generated/uapi -include ../include/linux/kconfig.h  -I../kernel/trace -Ikernel/trace -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE -mgeneral-regs-only -DCONFIG_AS_LSE=1 -fno-asynchronous-unwind-tables -fno-pic -mabi=lp64 -fno-delete-null-pointer-checks -O2 --param=allow-store-data-races=0 -DCC_HAVE_ASM_GOTO -Wframe-larger-than=2048 -fstack-protector-strong -fno-delete-null-pointer-checks -Wno-unused-but-set-variable -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -g -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fno-merge-all-constants -fmerge-constants -fno-stack-check -fconserve-stack    -DKBUILD_BASENAME='"bpf_trace"'  -DKBUILD_MODNAME='"bpf_trace"' -c -o kernel/trace/.tmp_bpf_trace.o ../kernel/trace/bpf_trace.c

Видно, что используется /home/fck/Mi_Kernel/andromeda-p-oss/toolchain/bin/aarch64-linux-android-gcc

Redfern89
() автор топика

Когда собирал twrp(правда под другой девайс и андроид8) из неочевидного и внезапно обламывающего сборку попалось необходимость сделать используемым по умолчанию второй питон и выставление LANG=C, может и тут оно?

TheFallenAngel ★★
()
Ответ на: комментарий от u5er

Там ошибки на сколько помню тоже выдавало не к питону, а сишные, но может путаю за давностью. Но помню в тот момент ещё было, что пришлось даунгрейдить хостовый компилятор, с 10 или 12 на тот момент на предыдущую версию, при том, что сборка шла не системным, однако ж помогло, тогда нагуглилось, что там умолчальные какие то настройки с версией поменяли - а оно видимо из хостовых и бралось.

На всякий случай возможно что то отсюда нужно:

### cat /etc/dpkg-cross/cross-config.amd64 
ac_cv_c_bigendian=no
ac_cv_c_char_unsigned=no

### cat /etc/dpkg-cross/cross-config.arm64
ac_cv_c_bigendian=no
ac_cv_c_char_unsigned=yes

#lots of things: turn off stack protector
libc_cv_fno_stack_protector=no

# Supplemental groups are disabled by default when crossing coreutils.
# Should this go in generic file?
ac_cv_func_getgroups_works=yes

#Syscall resumable test passes (ie wait syscall is resumable)
ac_cv_sys_restartable_syscalls=yes

#Void ptr longer than long
ap_cv_void_ptr_lt_long=no

#apr
#Verified with native test program
apr_cv_process_shared_works=yes
#Verifed with native test program
apr_cv_mutex_robust_shared=yes
#probably more general than just APR. verifed by cross compiling and running test from configure

# mysql
# mysql wants to know stack direction:
# STACK_DIRECTION > 0 => grows toward higher addresses
# STACK_DIRECTION < 0 => grows toward lower addresses
# STACK_DIRECTION = 0 => direction of growth unknown
ac_cv_c_stack_direction=-1
....

TheFallenAngel ★★
()
Ответ на: комментарий от TheFallenAngel

даунгрейдить хостовый компилятор, с 10 или 12

╭──(root😈ubuntu)-(5.4.0-150-generic)-[ 📂../Mi_Kernel/andromeda-p-oss ]
╰─> gcc -v

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/7/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu 7.5.0-3ubuntu1~18.04' --with-bugurl=file:///usr/share/doc/gcc-7/README.Bugs --enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr --with-gcc-major-version-only --program-suffix=-7 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie --with-system-zlib --with-target-system-zlib --enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 7.5.0 (Ubuntu 7.5.0-3ubuntu1~18.04) 
Redfern89
() автор топика
Ответ на: комментарий от TheFallenAngel

используемым по умолчанию второй питон

я так делал на Debian 12, сейчас я специально накатил на виртуалку Unbuntu 18.04.2, как в инструкции, в ней питон второй версии

╭──(root😈ubuntu)-(5.4.0-150-generic)-[ 📂../Mi_Kernel/andromeda-p-oss ]
╰─> python --version
Python 2.7.17

Redfern89
() автор топика
Ответ на: комментарий от Redfern89

я так делал на Debian 12, сейчас я специально накатил на виртуалку Unbuntu 18.04.2, как в инструкции, в ней питон второй версии

Ну это из пушки по воробьям. Чтобы python указывал на нужную версию, достаточно добавить в начало PATH нужный каталог (ну или создать и активировать virtualenv с нужным питоном, кому как удобнее)

annulen ★★★★★
()

Проблема в том, что при сборке используется gcc-wrapper, который превращает в ошибку любое предупреждение, кроме указанных в «белом списке». И никакие -Werror тут не причём, компилятор генерирует ворнинги, а строку error, forbidden warning уже печатает gcc-wrapper.

Одно из возможных решений здесь: https://telegra.ph/Gajd-Kak-pofiksit-bolshinstvo-oshibok-pri-sborke-yadra-Kak-otklyuchit-Werrory-i-gcc-wrapper-10-20

Другой вариант — пропатчить сам скрипт, чтобы не жужжал: https://patch-diff.githubusercontent.com/raw/Joshua-Riek/linux-rockchip/pull/4.diff

Но интересно, конечно, как сами авторы репозитория собирают своё ядро, не сталкиваясь с этой проблемой.

annulen ★★★★★
()
Ответ на: комментарий от annulen

Но интересно, конечно, как сами авторы репозитория собирают своё ядро, не сталкиваясь с этой проблемой.

Я думаю, что они не юзают gcc-wrapper. А так, бро, спасибо большое! Попробую чуть позже, возможно это именно мой случай

Redfern89
() автор топика
Ответ на: комментарий от annulen

Помогло, варнинги ушли (вернее они остались, но теперь они просто варнинги), появились другие ошибки, но они уже связанны с версией clang. Кстати этот метод помог в сборке ядра для realme c21y, однако китайские «горе-ядерщики» наделали ошибок в файле sprd_panel.c, пока не устранил все, но близок к этому, а так там тоже самое было практически

Redfern89
() автор топика