http://bfy.tw/GqZm

Я пробовал делать как написано в первом посте на стаке, файл собрался точно так же и весит ровно столько же.

Обычный -static использовать не можешь?

Ну так покажи нам свой CMakeLists.txt

Я добавил set(CMAKE_EXE_LINKER_FLAGS "-static") в CMakelists.txt, файл вырос но на других системах теперь не запускается.

https://pastebin.com/f4sCMK4A

Попробуй использовать dietlibc:

include_directories("/usr/lib/dietlibc/include")
set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -nostdinc -D__dietlibc__")
set(DIET "/usr/lib/dietlibc/lib-i386")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -static -nostdlib -L${DIET} ${DIET}/start.o")

Я установил эту библиотеку, прописал пути к ней, но при сборке куча ошибок посыпалась. Без этих флагов собирается нормально (но статически не связывается).

Юзай musl, у него с глибц лучше совместимость musl-libc.org

https://github.com/xmrig/xmrig/issues/238

Так, если я правильно понял, нужно с помощью musl собрать с и с++ компиляторы, потом собрать ими libuv и сам xmrig? Спасибо, попробую этим заняться.

Так, если я правильно понял, нужно с помощью musl собрать с и с++ компиляторы

Нет, не надо.

А все, дочитал, увидел что там собранный файл есть, спасибо, вопрос снят.

Я использую очень старый дистрибутив Linux для этого. CentOS 5 + компилятор GCC 4.8 из репозитория Devtoolset. Там Glibc 2.4. Или CentOS 6 + компилятор GCC 7 из репозитория Devtoolset. Там Glibc 2.12.

Можно ещё использовать Debian Etch или Squeeze, там 2.3 и 2.11. Но нет репозитория с новым компилятором.

Коротко можешь объяснить нубу, что там удобного в старых версиях компилятора?

В CentOS 5 и 6 штатные компиляторы - 4.1 и 4.4. Но можно обновить до 4.8 и 7

Главное что готовые бинарники не хотят GLIBC 2.22

А с 2.22 есть некошерные сложности? В чём сложность?

Сложность в том, что некоторые люди пользуются старым линуксом. Либо Ubuntu LTS, либо CentOS. Можно распространять новую прогу с новыми же bunbled-либами, и тогда проблем нет. Но вот положить с прогой новый Glibc нельзя. Вернее, можно, но способ нетривиален.

Так что я компиляю новый софт в старой билд-ферме. Новым компилятором.

В очередной раз порадуюсь за тех людей, которые не пользуются такими сборочками. Сколько у тебя пользователей, примерно треть землекопа?

Какими - такими?

Например вот: http://store.steampowered.com/app/360940/The_Mean_Greens__Plastic_Warfare/

Игра на движке UE4, минимальные системные требования:

    ОС: kernel 2.6.32 or newer & glibc 2.12.2 or newer
    Процессор: Quad-core Intel or AMD, 2.5 GHz or faster
    Оперативная память: 4 GB ОЗУ
    Видеокарта: OpenGL 4.1 compatible graphics card
    Сеть: Широкополосное подключение к интернету
    Место на диске: 14 GB

Если бы все так делали, не надо было бы тащить со стимом - такой огромный Runtime. А ещё лучше - пусть будет ключик такой при компиляции, чтобы возможности Glibc новее такой-то версии (например 2.12) не использовались. Собирай хоть в Ubuntu 18.04, только ключик указывай.

А вот так делать не надо:
http://store.steampowered.com/app/328100/Gunspell__Steam_Edition/
http://store.steampowered.com/app/506900/Downward/

Первая собрана в Ubuntu 10.10, вторая - в 16.10. Притом что так много пользователей LTS-версий Убунт. При запуске, такие пользователи обязательно отхватят «требуется glibc x+1, а у вас glibc x». С первой игрой уже не актуально - тот же Стим для запуска требует 12.04 минимум, а вторая всё ещё вызывает проблемы у части пользователей!

Благодарю. Нихрена себе камни.

Есть пару вопросов

Если будет время, можешь ответить?

1. STL+IDE - это благо или зло? Ускоряет процесс создания или это для быдлокодеров, а программисты используют только Vim и встроенные инструменты?

2. Если в планах только системное программирование в Linux на C, можно ли обойтись без ООП C++ или всё же закупаться книгами по крестам?

Заранее благодарен.

Я не проггер, я только мейнтейнер. Только собираю при помощи configure, make и make install. Поэтому ответить на вопрос не могу.