Нельзя, Столман покарает.

Карать, надеюсь, будут свободными предметами? )

А уже существуют свободные дилдаки?

Но зачем?

Вот и я не знаю. )

смотри теги

Хочется новых ощущений - напиши своё ядро.

Не смогла

[d_a@home linux-4.14.4]$ make CROSS_COMPILE=x86_64-w64-mingw32- V=1 bzImage
make -f ./scripts/Makefile.build obj=arch/x86/entry/syscalls all
make -f ./scripts/Makefile.build obj=scripts/basic
rm -f .tmp_quiet_recordmcount
make -f ./scripts/Makefile.build obj=arch/x86/tools relocs
set -e; : '  CHK     include/config/kernel.release'; mkdir -p include/config/; 	echo "4.14.4$(/bin/sh ./scripts/setlocalversion .)" < include/config/auto.conf > include/config/kernel.release.tmp; if [ -r include/config/kernel.release ] && cmp -s include/config/kernel.release include/config/kernel.release.tmp; then rm -f include/config/kernel.release.tmp; else : '  UPD     include/config/kernel.release'; mv -f include/config/kernel.release.tmp include/config/kernel.release; fi
make -f ./scripts/Makefile.asm-generic \
            src=uapi/asm obj=arch/x86/include/generated/uapi/asm
make -f ./scripts/Makefile.asm-generic \
            src=asm obj=arch/x86/include/generated/asm
set -e; : '  CHK     include/generated/uapi/linux/version.h'; mkdir -p include/generated/uapi/linux/; 	(echo \#define LINUX_VERSION_CODE 265732; echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';) < Makefile > include/generated/uapi/linux/version.h.tmp; if [ -r include/generated/uapi/linux/version.h ] && cmp -s include/generated/uapi/linux/version.h include/generated/uapi/linux/version.h.tmp; then rm -f include/generated/uapi/linux/version.h.tmp; else : '  UPD     include/generated/uapi/linux/version.h'; mv -f include/generated/uapi/linux/version.h.tmp include/generated/uapi/linux/version.h; fi
rm -f include/linux/version.h
set -e; : '  CHK     include/generated/utsrelease.h'; mkdir -p include/generated/; 	if [ `echo -n "4.14.4" | wc -c ` -gt 64 ]; then echo '"4.14.4" exceeds 64 characters' >&2; exit 1; fi; (echo \#define UTS_RELEASE \"4.14.4\";) < include/config/kernel.release > include/generated/utsrelease.h.tmp; if [ -r include/generated/utsrelease.h ] && cmp -s include/generated/utsrelease.h include/generated/utsrelease.h.tmp; then rm -f include/generated/utsrelease.h.tmp; else : '  UPD     include/generated/utsrelease.h'; mv -f include/generated/utsrelease.h.tmp include/generated/utsrelease.h; fi
mkdir -p .tmp_versions 
make -f ./scripts/Makefile.build obj=.
mkdir -p kernel/
  x86_64-w64-mingw32-gcc -Wp,-MD,kernel/.bounds.s.d  -nostdinc -isystem /usr/lib/gcc/x86_64-w64-mingw32/5.4.0/include -I./arch/x86/include -I./arch/x86/include/generated  -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -fno-pie -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -fshort-wchar -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-PIE -fno-pie -mno-sse -mno-mmx -mno-sse2 -mno-3dnow -mno-avx -m64 -falign-jumps=1 -falign-loops=1 -mno-80387 -mno-fp-ret-in-387 -mpreferred-stack-boundary=3 -mskip-rax-setup -mtune=generic -mno-red-zone -mcmodel=kernel -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -DCONFIG_AS_FXSAVEQ=1 -DCONFIG_AS_SSSE3=1 -DCONFIG_AS_CRC32=1 -DCONFIG_AS_AVX=1 -DCONFIG_AS_AVX2=1 -DCONFIG_AS_AVX512=1 -DCONFIG_AS_SHA1_NI=1 -DCONFIG_AS_SHA256_NI=1 -pipe -Wno-sign-compare -fno-asynchronous-unwind-tables -O2 -fno-omit-frame-pointer -fno-optimize-sibling-calls    -DKBUILD_BASENAME='"bounds"'  -DKBUILD_MODNAME='"bounds"'  -fverbose-asm -S -o kernel/bounds.s kernel/bounds.c
kernel/bounds.c:1:0: error: code model kernel does not support PIC mode
 // SPDX-License-Identifier: GPL-2.0
 ^
make[1]: *** [kernel/bounds.s] Ошибка 1
make: *** [prepare0] Ошибка 2

PS. MinGW у меня всё равно самосборный, можно было попробовать переконфигурить его без pie, но делать этого я не буду конечно же.

Я думаю что вполне, но mingw тут не в тему. Возможно тебе самому придется скомпилить компилер. Ну и зафиксить несколько багов по дороге.

Не знаю, что насчёт Windows, но под macOS ядро Linux вполне собирается.

Столлману не обязательно что-то делать. У make под вендой время вызова внешнего процесса (gcc) садомазохистски велико. Даже если через cygwin эта шняга соберется, время сборки и дичайший геморрой при разработке будет достойной карой тому, кто на такое извращение решился.

TS скорее всего имеет в виду gcc из mingw из винды, а не кроссом на mingw компеляторе. Т.е. у тебя должен быть виндузовый тулчейн, генерирующий линуксовый код (что возможно).

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

ну, сам gcc-mingw я под маздаем собирала. правда, это было ещё очень давно. как уже выше заметили, это чрезвычайно долго, потому что маздай и тормоза кругом. во-вторых, надо ставить кучу юниксовых утилей типа awk, grep и иже с ними, плюс patch потому что при сборке часто накатываются патчи и всякое такое. ну и ещё один минус, что gcc под mingw жрёт какое-то невообразимое количество рамы. просто нереальное. и сворачивать в своп её не хочет. поэтому может оказаться, что в критический момент просто рамы не хватит. так что не могу сказать, что кернел соберётся.

Почитай CLFS, может быть это поможет.

Вроде как можно (Linux 0.11 on Windows 10/MinGW)

ну, сам gcc-mingw я под маздаем собирала. правда, это было ещё очень давно

...и неправда.

У make под вендой время вызова внешнего процесса (gcc) садомазохистски велико.

Ах вот оно в чём дело...

Я замечал, что мой проект из где-то полусотни файлов *.cpp под виндой (mingw32) собирается заметно медленнее, чем под линуксом, и долго гадал, кто виноват - g++ или make.

Интересно, это неустранимая особенность винды или таки косяк make, недостаточно качественно перенесённого на данную платформу?..

https://stackoverflow.com/a/29766609

Many «unixy» things on MinGW are painfully slow, because Windows has no fork(). Windows only has CreateProcess(), which is quite different. Unix shells and GNU Make do a lot of forking, so running these under MinGW results in «emulated» forks, which are really slow. ...

У make под вендой время вызова внешнего процесса (gcc) садомазохистски велико.

Не только у make, ещё и у всех утилит autotools. Под виндой в сочетании с MSYS (MinGW) или Cygwin они работают с убертормозами.

Интересно, это неустранимая особенность винды или таки косяк make, недостаточно качественно перенесённого на данную платформу?..

Конечно же это косяк этой древней UNIX-утилиты, на которую всем уже начхать. Если избавится от make в пользу CMake/ninja или на тот же jom https://wiki.qt.io/Jom (у тебя ведь Qt-проект?), то время сборки сокращается существенно.

Ну или с помощью MSVC можно собирать проекты, для Qt официально есть специальный плагин, который отлично работает с Community версией Visual Studio.

Конечно же это косяк этой древней UNIX-утилиты, на которую всем уже начхать.

Толстенько звучит, я думаю, у участников проекта GNU другое мнение. Другое дело, что оригинальная make - это одно, а её порт на винду - немножко другое. Может, в материалах проекта MSYS покопаться...

Если избавится от make в пользу CMake/ninja

Вообще, незадолго до первого публичного релиза DoubleContact я пытался перевести сборку на cmake. Но с моими специфичными хотелками я скоро обнаружил, что уже несколько дней вместо развития проекта воюю с системой сборки. В итоге я эту затею отложил на неопределённый срок. А вместо плюшек cpack (ради которого это всё во многом затевалось) сколхозил отдельные скрипты для сборки RPM/DEB.

А кстати, qmake ведь тоже умеет с ninja работать, или я чего-то путаю?..

Понятно, печально...

Другое дело, что оригинальная make - это одно, а её порт на винду - немножко другое. Может, в материалах проекта MSYS покопаться...

Ну вот Qt-разработчики не зря же jom клепали под винду, верно? Их не устроила скорость работы ни GNU-того make, ни MS-овского nmake.

А кстати, qmake ведь тоже умеет с ninja работать, или я чего-то путаю?..

Скорее всего что-то путаешь. В QMake никогда не было поддержки Ninja: http://lists.qt-project.org/pipermail/development/2014-May/017056.html

Вообще, незадолго до первого публичного релиза DoubleContact я пытался перевести сборку на cmake. Но с моими специфичными хотелками я скоро обнаружил, что уже несколько дней вместо развития проекта воюю с системой сборки.

Мне тоже жутко не нравится угрёбищный CMake, но пока он выигрывает из-за своей распространённости.

А в том же QMake захардкоженный стиль расстановки скобочек {} вызывает умиление.

Почитал про применение jom здесь. Я правильно понял, что судя по приведённым командам, jom потребляет обычный Makefile, сгенерированный qmake?..

Да. Последние абзацы в этой статье об этом прямо говорят.

Вот только не знаю, что там с поддержкой современной винды. Я тыкал jom достаточно давно, во времена 5.1.0 примерно. Ситуация могла измениться и его могли объявить устаревшим. Но вроде официальная документация 5.10 всё ещё его упоминает.

http://doc.qt.io/qtcreator/creator-build-process-customizing.html

https://www.comingle.io/

ЕМНИП, были извращенцы, которые пытались ядро с помощью MSVC собрать

ну да, ну да, в fork() не умеет винда, а виноваты автотулзы

нет, это правда. только требует очень много времени. и главное - памяти. какой-то непонятный глюк то ли с маздайным make, то ли с собранным под ним gcc. но он жрёт раз в десять больше памяти, чем реально нужно для сборки.