Как использовать GCC вместо Clang++?

Так поменяй компилятор в make файле

В makefile вообще нет указания на компилятор.

1. CC=gcc,

2. также можно ./configure CC=/usr/bin/gcc или

3. можно в configure.ac исправить AC_PROG_CC так AC_PROG_CC([gcc])

4. или подправить компилятор по умолчанию в configure.ac перед вызовом AC_PROG_CC так CC=${cc-/usr/bin/gcc},

правда ваш путь к гцц может отличаться, узнать можно whereis gcc

Прбовал CC=gcc и make CC=gcc. Не помогает.

В configure.ac есть только такое:

# Checks for programs.
AC_PROG_CPP
AC_PROG_CXX
AC_PROG_CXXCPP

# Checks for languages.
AC_LANG_CPLUSPLUS

AC_PROG_CXX это и есть компайлер для C++

2021 год, autotools по прежнему полощет мозг юзеру, как и четверть века назад.
А разве не g++ надо вызывать?

Возможно, у тебя clang где-то закэширован. Удали всё и начни по новой.

Ну очевидно же, что в случае плюсов AC_PROG_CXX([g++]) или предыдущие варианты, с поправкой на компилятор плюсов, плюс вообще стоит проверить наличие g++

В makefile:331 используется qmake. Возможно, это он категорически требует clang. И как быть?

$(name).mak:	$(name).pro
	@$(QMAKE) -o $(name).mak $(name).pro

Это говно свалится по ошибке в строке одинадцать тысяч пятьсот блядь двадцать пять. И что мы увидим в этой строке? Функцию report_error. Будет ли там стектрейс? Конечно нет.

:-(

По секрету скажу, что meson тоже не умеет.

Я не умею в autotools, но, как юзер, понял одну вещь: если разраб в него плохо умеет, autotools не будет конфигурироваться НИГДЕ, кроме окружения, идентичного окружению разработчика. И это дико бесит.

В моей Дженте таких проблем с autotools не встречал, а с meson - да. Обход проблемы есть, но всё равно бесит.

Так то gentoo.
А вот если чего из сорцов руками...

Это очень странно так как обычно проекты использующие autotools им же и собираются, для qmake указать нужный компилятор можно через переменные окружения QMAKE_CXX и QMAKE_CC

Ну, это означает, что проблема не в Autotools, а в qmake.

Объективно, признавая справедливость всех претензий к Autotools, скажу, что, при наличии у разработчика рук, всё будет работать. Как, впрочем, и в случае с qmake.

Что делать? Разбираться.

Либо выложить исходники.

Либо написать автору проекта.

CC=/usr/local/bin/gcc11
CXX=/usr/local/bin/g++11
CPP=/usr/local/bin/cpp11

в /etc/make.conf.

В моей Дженте таких проблем с autotools не встречал, а с meson - да.

У меня Meson работает везде включая Haiku и Windows. Видимо дистрибутив/файлы сборки кривые.

:-(

Вы же вроде бы Autotools продвигали? Его неумение нормально показывать ошибки — это ОК?

libtool всегда была куском говнокода, это правда.

Ты перепутал меня с типичной местной аудиторией, которая всегда топит за свой единственно верный курс, наплевав на логику и здравый смысл.

libtool всегда была куском говнокода, это правда.

Оно часть Autotools, так что и Autotools наследует статус «куска говнокода». Не вижу попыток переписывания libtool или его замены на что-то другое. Лучше сразу весь набор Autotools на помойку.

Autotools часть Линукса, так что и Линукс наследует статус «куска говнокода». Не вижу попыток переписывания Autotools или его замены на что-то другое. Лучше сразу весь Линукс на помойку.

Autotools часть Линукса, так что и Линукс наследует статус «куска говнокода».

Под Линукс можно писать без Autotools, а насчёт Autotools без libtool не уверен.

В самом скрипте ничего ужасного нет, он просто старый и с длинным техническим долгом.

Ну ты же не был тем героем, который помог бы GNU переписать это нагромождение костылей, правильно?

Вместо кооперации и взаимопомощи люди предпочитают тянуть одеяло на себя.

Ну ты же не был тем героем, который помог бы GNU переписать это нагромождение костылей, правильно?

Зачем если есть более адекватные решения Cmake и Meson (а также Jam, SCons и т.д., да почти всё угодно лучше Autotools)? Я только за скорейшую кончину всех компонентов Autotools.

Вместо кооперации и взаимопомощи люди предпочитают тянуть одеяло на себя.

Я только за скорейшую кончину всех компонентов Autotools.

Очень типично.

Примерно как демократы, которые готовы расстрелять всех, кто не согласен с демократией.

Неее, с мезоном столько боли не было. Закидываешь ему тулчейны и всё работает. Есть проблема, что они периодически что-нибудь депрекейтят/обновляют, из-за чего приходится подпиливать, но в целом – норм, хотя бы без этой фрустрации с «попробуй догадайся что в этой шелл лапше на 25к строк опять сломалось».

Очень типично.

В чём ценность этого копролита, что его обязательно надо чинить? Был бы нужен, уже бы давно починили.

Суть в том, что тебе не достаточно пользоваться свои мезоном, нужно обязательно всех построить.

Но тут не тоталитарная секта.

Всё перепробовал, ничего не помогает. Файла /etc/make.conf вообще нет. Я его создал для пробы, но ничего.

Пробовал QMAKE_CXX и QMAKE_CC в разных вариантах. Не помогает. Уточните, пожалуйста, как точно их применять?

Короче, без Clang не обойтись. Пришлось поставить его обратно и разобраться в ошибках, которые он выдаёт. Оказалось, что ему не хватает оперативной памяти. Пришлось сделать файл подкачки.

clang-11: error: unable to execute command: Terminated
clang-11: error: linker command failed due to signal (use -v to see invocation)

Потом вылезли ошибки ld. Нашёл совет, что нужно добавить -ldl в конце linker flags. В моём случае это был второй Makefile, который создаёт Qmake в папке src, строка LFLAGS.

ld: error: undefined symbol: dlopen
ld: error: undefined symbol: dlclose
ld: error: undefined symbol: dlsym

миф какой-то. Хейтер чтоль?

Бред какой-то.
Что ты пытаешься сделать? Что-то скомпилить? Опенсорц проект или копипаста со стековерфлоу?

Ну бред же говоришь. конфигур просто идеально говорит чего не хватает и что фейлится. Пожет просто опыта маловато и не понимаешь слов?

Мне как пользователю нравится, но свои проекты я никогда этим собирать не буду %)

чезабред, так кумейк или автотулз? Или одно или другое :)

Мне как пользователю нравится

…пока не решите собирать на системе/дистрибутиве, сильно отличающегося от того, который использовал автор софта. Чинить файлы сборки Autotools — это ужас.

Или одно или другое :)

Сумрачные гении могли и совместить.

Никогда проблем со сборкой не было, собираю обычно на Slackware.

Никогда проблем со сборкой не было, собираю обычно на Slackware.

А теперь попробуйте в BSD, Nix, Alpine Linux, Haiku.

Под FreeBSD много чего собирал, но все было популярное, типа Emacs.

Я бы это в другую сторону сформулировал.

Если автотулз вдруг конфигурируется на чем-то отличном от дистра/архитектуры разраба или того, что у проекта включено в CI, это почти безошибочный признак, что либо в истории коммитов есть как минимум один не старше двух лет с заголовком .*(<fix>|autotools) .*<platform>.*, либо проект замшел до небывалой стабильности и тогда придётся прочесать последние коммитов 200, либо он прячется где-то как даунстрим-патч.

Бред, не бред, но программу собрал. Всё работает. Это Qtractor - секвенсор для звуковых плагинов, простенькая DAW.

Ну бред же говоришь. конфигур просто идеально говорит чего не хватает и что фейлится.

Давай перечитывай, фейлится не configure, а libtool.

Пожет просто опыта маловато и не понимаешь слов?

Сказал персонаж, который не отличает configure от libtool %)

И да, собираю я, например, с линукс хоста шлангом+мингв64црт, чтобы запускалось на шиндоуз. Если на твоей локалхостной слаке с ровно одним тулчейном и одним набором библиотек это говно работает – рад за тебя, но о портабельности или надежности это ничего не говорит.

Последние лет десять только и занимаюсь что cross-compile для не-x86, для всяких arm, mipsel, sh4, и опыт показал что меньше всего проблем с autotools, а вот cmake крайне капризен.

cross-compile для не-x86

Тут скорее важен дистрибутив, а не процессор.

да откуда он знает про твои депенданси