А я про это и не говорю ничего

Интересно, что ты имел в виду под «проверять среду».

что ты имел в виду под «проверять среду».

Хм, щас погонял ./configure от разных прог, не так уж медленно работает. Но раньше оно могло минутами что-то там конфигурить аля «а по какому пути установлен objdump который нафиг при сборке не сдался». Или «checking size of double».

Писать тесты, прогонять через valgrind это же скучно. Люди и так за идею работают.

Тут сообщение об ошибке совершенно не отражает сути происходящего. И я считаю это неправильным.

Другое дело что, например, исправление этого может потребовать значительных усилий. Но это уже второй вопрос.

тут не сделать нормально, сообщения компиляторов не стандартизированы, если запускать тестовые бинарники - будут проблемы с кросскомпиляцией. Может быть, стоит показывать этот выхлоп.

оно же модульное, сколько разработчик сделает тестов, столько и будет

если запускать тестовые бинарники

Но именно так оно часто и поступает, разве нет? При кросс-конпиляции просто эти тесты опускаются.

Стандартные тесты из поставки autoconf - нет (проверки функций, библиотек, etc). Самописные могут запускать.

чтобы исправить ошибку - необходимо хранить информацию о ней. если она, эта информация, будет только в экранном буфере - замахаешься ее исправлять

Не зря я поставил напротив вашего ника заметку «ненормальный». Это хорошая фича движка ЛОРа.

Покажите товарищу «Error: Success» что ли, а то он какой-то нервный.

ололо, баттхёрт неосиляторов autoconf ITT :)

всем читать http://www.gnu.org/software/autoconf/manual/autoconf.html до достижения нирваны

Имеет смыл проверять только самые важные вещи, а не «а есть ли в этой системе функция printf, а каков размер char».

проверяется только то, что указал аффтар в configure.ac, претензии к нему, а не к автотулзам

cannot compute suffix of object files: cannot compile

это configure выдаёт глобальную ошибку, типа у него что-то не получилось, а конкретные причины этой ошибки нужно искать в config.log в той директории, на которой процесс конфигурации упал

configure проверяет то, что ему сказал проверять автор программы. Если он сказал «проверь objdump» - наверное, ему это нужно.

в таком случае сначала подучи матчасть (хотя бы тот же lfs), а потом уже мечи сопли на тему «разрабы - казлы»

Я не настолько её не знаю, я читал и даже собирал LFS.

Но чтобы определить, что «cannot compute suffix of object files» на экране и по совершенно непонятной причине падающая вторая стадия сборки в логах вызваны мультилибом, и что для сборки я должен дать параметр "--disable-multilib" я догадался только путём применения особой лунной логики.

И хренли ты это не починил?

Уметь компелять != уметь писать программы.

configure проверяет то, что ему сказал проверять автор программы

Это всегда было так или только в последние лет 10?

Есть особая каста товарищей которая считает что автолулзы божественны. Им ничего не докажешь.

Насколько я знаю, так было всегда. Возможно, набор тестов изменился в связи с тотальным доминированием GNU-тулчейна.

Ты как будто /usr/src/linux/Documentation/init.txt никогда не читал.

А это

Required libraries for the GCC build are missing, specifically MPFR, GMP and MPC. If installed as shared libraries they must be in the runtime linker's search path so they can be found.

Ты проверил?

А это
Ты проверил?

Я про это уже выше писал:

Твой код говно? Ничего! Просто задокументируй это! (комментарий)
Твой код говно? Ничего! Просто задокументируй это! (комментарий)

    (v15, 2012-06-22, Piers Daniell)
        - Restored the ARB suffixes removed by mistake.

    (v13, 2012-04-19, pdaniell)
        - Remove ARB suffixs to make the extension ready for OpenGL 4.3.

феерия.

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

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

Ну да, младший шаман должен сначала поучиться у старшего шамана...

Если бы духи высказывали свою волю более понятно, не надо было бы никакого техножречества, не так ли?

а что непонятного-то? системой сборки был запущен тест для определения суффикса объектных файлов, который нужен для генерации правил в мейкфайлах. тест не прошел, о чем система сборки тебе и сообщила. а уж определить, почему он не прошел - это твоя задача. для этого есть и расширенный лог, и описание наиболее возможных причин подобных сбоев в доках. ну и собственный опыт, естественно.

и ныть на тему «хуль эти редиски не используют в своих системах libastral.so» здесь вовсе не обязательно

а уж определить, почему он не прошел - это твоя задача.

А почему, собственно, это моя задача?

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

Вот это рвение. А тут... «Оно запустило один тест, тест провалился, дальше уж сам ковыряй. Что в этом непонятного?»

и ныть на тему «хуль эти редиски не используют в своих системах libastral.so» здесь вовсе не обязательно

Да уж прям не используют. Ихние скрипты конфигурации — это же libastral версии 0.1. Проблема только в том, что версия сильно недоработанная.

Но ныл я не совсем на эту тему. Я не ныл, я был очень удивлён. Тем фактом, что даже авторы FAQ на сайте GCC отмечают, что:
This error message is quite misleading and frequently the problem has nothing to do with the message.

Тебе не кажется, что когда сообщения об ошибках в программе «misleading and frequently the problem has nothing to do with the message» — это ненормально?

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

В какой-то другой, маленькой комнатной программке?

Ну, да. gcc мне собирать пока не доводилось.

А в данном конкретном случае это GCC.

В данном случае это универсальный инструмент (autotools), вы же не хотите, чтобы для gcc была его персональная сборочная система?

А собирать-то нужно конкретный проект.

Каждому проекту по форку autotoools. :)

Специалисты в чём?

В програмировании, вероятно. Способные прочитать ответ компилятора и понять что ему не нравится. В противном случае не очень полнятно зачем gcc.

А я вовсе не специалист в устройстве компиляторов.

А в использовании?

Что это меняет?

Выхлоп - текст предназначеный для человека, который надо распарсить ради красивого сообщение об ошибке. Имхо, проще сохранить весь вывод и дать человеку его прочитать.

иначе даже специалист будет долго разбираться.

В faq специалисту сказано где читать описание об ошибке в этом случае.

А если там сообщение «произошла ошибка сборки» то гуглить это практически бесполезно.

Да, надо как советуют в faq - открыть config.log и прочитать что на самом деле случилось.

Я уже устал, но всё же не останволюсь!

В данном случае это универсальный инструмент (autotools), вы же не хотите, чтобы для gcc была его персональная сборочная система?

Хороший универсальный инструмент — это тот, который адаптируется к любой ситуации. А если кто начнёт забивать молотком шурупы, то это не значит, что молоток — универсальный инструмент.

Каждому проекту по форку autotoools. :)

Не каждому, а вот GCC бы, вероятно, помогло. Люди и в гораздо более простых случаях, чем самособирающийся компилятор, пишут свои сборочные системы.

В програмировании, вероятно. Способные прочитать ответ компилятора и понять что ему не нравится. В противном случае не очень полнятно зачем gcc.

Компилятор ругался на отсутствие файла «bits/predefs.h». В большинстве случаев это означает, что такого файла нет в системе. Но, как нетрудно догадаться, файл этот в системе присутствовал, а то бы уже первая стадия сборки вряд ли бы могла завершиться. Я, собственно, до сих пор не понимаю, почему те флаги, которые я выставил, привели именно к такой ошибке на второй стадии.

PS пользователь scons, waf и python distutils.

Как мэйнтэйнер пакетов, заявляю: scons - так себе, waf - адЪ, distutils - очень даже ничего, но для не-Python проектов практически непригодно. autotools и cmake - это 2 вменяемые билдсистемы, которые я видел. Одна более низкоуровневая и требует ручной доводки(autotools), другая - более дружелюбная, но нетривиальные вещи в нем запаришься делать(cmake).

Про самописные билд-системы я вообще промолчу - эти вещи часто бывают за гранью добра и зла