LINUX.ORG.RU
ФорумTalks

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

 autohell, , , альтернативное мышление


0

1

Собираю GCC 4.8.1. Ловлю знаменитую ошибку:

cannot compute suffix of object files: cannot compile

Решил поглядеть в интернете, какие могут быть (на этот раз) причины. Захожу на «официальную» wiki GCC. И в самом деле, там в FAQ упоминается эта ошибка:

http://gcc.gnu.org/wiki/FAQ#configure_suffix

Configuration fails with "configure: error: cannot compute suffix of object files: cannot compile". What is the problem?

(...)

This error message is quite misleading and frequently the problem has nothing to do with the message.


...занавес...

★★★★★

Последнее исправление: proud_anon (всего исправлений: 1)

Зато GPL, и злые BSD-воры не смогут его закрыть.

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

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

Путём пересаживания разработчиков GCC с autotools на что-нибудь порядочное? Не могу, волшебная палочка в ремонте.

Потом, зачем чинить? Это, ИМХО, такой высококлассный троллинг, что даже Линус Трольвальдс курит в сторонке.

proud_anon ★★★★★
() автор топика

И что? Думаешь эту ошибку не исправляют специально?
Видимо х.з. что с ней делать.
Компилятор это тебе не очередной тетрис.

Какие-то вы странные последнее время. Вчера какой-то тип говорил, что мерседесы говно, а их инженеры идиоты из-за того, что они что-то там натупили с коробкой передач. Это при том, что огромное количество другого их оборудования работает нормально.
Текущий ТС объявляет GCC говном лишь потому, что там есть какая-то сложная и невыковыриваемая ошибка. Да, они её задокументировали. А ты что предлагаешь? Хранить в тайне, чтобы нормальные люди вообще охреневали столкнувшись с таким?

Где вас упорышей таких берут? Идеалисты пробирочные.
Тьфу...

Stahl ★★☆
()

...занавес...

А здесь перед нами типичный случай выдёргивания из контекста. Там же дальше написано где искать причину ошибки.

atrus ★★★★★
()
Ответ на: комментарий от ranka-lee

Ты же всерьёз не ждёшь качества от людей работающий «за идею»?

Странно... ты должен был умереть маленьким, как и все анацефалы, но дожил аж до постинга на ЛОР.

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

А здесь перед нами типичный случай выдёргивания из контекста. Там же дальше написано где искать причину ошибки.

Угу. Написано буквально следующее: нужно проигнорировать данное сообщение, залезть в config.log (причём ещё определить, в какой именно) и искать, что там на самом деле отвалилось.

proud_anon ★★★★★
() автор топика
Ответ на: комментарий от ranka-lee

Ты же всерьёз не ждёшь качества от людей работающий «за идею»?

Просто есть очевидные вещи, кмк. Например, «делайте внятными сообщения об ошибках», «проверяйте возвращаемые значения», «прогоняйте код через valgrind», «пишите тесты»...

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

Что значит какой именно? У меня config.log всегда один. Я уже не говорю о том, что в 90% случаев причина сбоя configure одна - не хватает заголовочных файлов. И там в faq даже написано какие именно библиотеки надо проверить на наличие.

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

Например, «делайте внятными сообщения об ошибках»

В данном случае внятное сообщение об ошибке имеет сложность от очень большой до невероятной, потому что в данном случае - сообщение об ошибке - выхлоп компилятора, который в общем случае может быть и не gcc (ведь это же универсальная сборочная система).

А читают эти сообщения - специалисты. А для специалиста можно и отступления от этих правил делать, если их соблюдение себе дороже.

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

Что значит какой именно? У меня config.log всегда один.

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

А вот у GCC их вот сколько:

% find . -iname 'config.log'
./gcc/config.log
./lto-plugin/config.log
./build-x86_64-unknown-linux-gnu/libiberty/config.log
./build-x86_64-unknown-linux-gnu/fixincludes/config.log
./x86_64-unknown-linux-gnu/libgcc/config.log
./x86_64-unknown-linux-gnu/libgomp/config.log
./x86_64-unknown-linux-gnu/libstdc++-v3/config.log
./libiberty/config.log
./libdecnumber/config.log
./intl/config.log
./config.log
./zlib/config.log
./libbacktrace/config.log
./libcpp/config.log

И это ещё сборка не закончена, и включены только три языка.

Я уже не говорю о том, что в 90% случаев причина сбоя configure одна - не хватает заголовочных файлов.

Если бы... эта ошибка из топика возникает из-за всего чего угодно, кроме понятных и легко исправимых причин. К счастью, если в системе вообще нет нужных библиотек или их хедеров, GCC ругается внятно и чётко.

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

выхлоп компилятора, который в общем случае может быть и не gcc

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

ведь это же универсальная сборочная система

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

А читают эти сообщения - специалисты.

Специалисты в чём? Я вот сейчас его читал. А я вовсе не специалист в устройстве компиляторов.

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

а накой ты полез собирать гцц руками, если не понимаешь механику процесса сборки?

Потому что мне нужен был новый гцц, а пакетов под свой дистр я не нашёл.

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

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

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

Не убедил.

сообщение об ошибке - выхлоп компилятора, который в общем случае может быть и не gcc

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

А читают эти сообщения - специалисты

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

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

true_admin ★★★★★
()

Как известно, задокументированная бага — это фича, поэтому GNU-программы — самые фичастые.

wintrolls ☆☆
()
Ответ на: комментарий от true_admin

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

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

ananas ★★★★★
()
Последнее исправление: ananas (всего исправлений: 1)
Ответ на: комментарий от ananas

засеривать экран лишней информацией

Пардон, а ты что, вдумчиво читаешь многокилометровые логи сборки gcc?? Как раз самое главное это сообщение об ошибке чтобы её можно было исправить не лазая в логи.

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

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

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

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

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

Глупость. Лог — это запись экрана. Хотя да, в последнее время стало модно вместо полезной информации вертеть какую-то 3D финтифлюшку на экране или дурацкие прогрессбары показывать.

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

Это же стандартные сообщения autotools. Тащемта специалисту неплохо бы минимально понимать механизм работы autotools.

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

Ребят, вы путаете тёплое с мягким.

Вы меня убеждаете что autotools нельзя сделать лучше. Прям как в анекдоте «учись студент, а то так и будешь ключи подавать».

Я обсуждаю конкретный изъян в его дизайне, если что. А не «что должен уметь специалист».

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

Лог — это запись экрана.

не обязательно, хотя зачастую и справедливо. не зря ведь stdout и stderr разделены.

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

вопрос не в (не)нужности сообщений об ошибках, а в способе их хранения/предоставления пользователю

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

не все склонны считать данный подход изъяном

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

в способе их хранения/предоставления пользователю

Вот пусть и пишет «смотрите в логи».

не все склонны считать данный подход изъяном

Именно поэтому очень полезно уметь влезть в шкуру других людей и посмотреть другими глазами. Это чтобы завтра, например, логи из autotools не выпилили потому что мейнтейнер «не считает данный подход изъяном».

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

Вот пусть и пишет «смотрите в логи».

это написано в любой доке по автотулзам. на кой хрен это дублировать для идиотов^W «простых домашних юзеров»?

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

У тебя началась попаболь которая мешает думать. Теперь чтобы собрать пакет нужно сначала изучить весь autotools, да?

И в этом я вижу большую проблему: люди за годы привыкают к костылям и по-другому «ходить» уже не умеют.

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

У тебя началась попаболь которая мешает думать. Теперь чтобы собрать пакет нужно сначала изучить весь autotools, да?

не нужно заглядывать мне в жопу и выносить диагноз.

ДА, чтобы собрать пакет, необходимо понимать принципы сборки. иначе получаются обезьяньи ужимки и сопли на толксах.

И в этом я вижу большую проблему: люди за годы привыкают к костылям и по-другому «ходить» уже не умеют.

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

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

необходимо понимать принципы сборки.

Что за принципы-то? По очереди натравить gcc на файлы и потом вызвать линкер? В том-то и дело что принципы весьма просты, а то что делают эти все auto*-тулзы это тихий ужас.

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

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

Ой да ладно. Есть экземпляры вроде тебя. До сорока доживают.

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

По очереди натравить gcc на файлы и потом вызвать линкер?

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

я очень сомневаюсь, что scons или waf способен в ходе работы оценить результаты предыдущего теста на предмет, а стоит или нет показывать его сообщения об ошибках.

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

и что ты в этом случае с захардконенными путями делать будешь

Ну ёлки-палки :(. Ну, добавь это тоже в список.

Я ожидал что-то в духе «а зато configure умеет окружение проверять». Вот было бы интересно послушать мысли на тему на сколько это всё нужно. По-моему, сейчас это практически не нужно.

а стоит или нет показывать его сообщения об ошибках.

Если есть ошибка они её показывают. В данном случае это более актуально для waf т.к. у scons явной фазы «configure» нет.

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

просмотрел документацию на scons по диагонали, поведение точно такое же как и у autoconf: на консоль печатается то что указано в правилах, полный лог в config.log

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

и что в результате? есть десять проверок наличия в системе десяти хидеров, по результатам обнаружения которых включается тот или иной опциональный код. что, на каждый необнаруженный хидер вываливать простыню сообщений об ошибках, причем с условиями их возникновения, исходным кодом теста и т.д.? не утонешь ты в такой информативности НА ЭКРАНЕ?

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

Опять не о том. Если scons найдёт проблему то он о ней выведет вменяемое сообщение об ошибке (по крайней мере я так думаю). Вот (примерно) как надо делать: http://www.scons.org/wiki/SconsAutoconf

А вот как не надо:

if gcc.version < 3.7:
  # счастливой отладки, суки (c) :)
  return 1
true_admin ★★★★★
()
Ответ на: комментарий от ananas

Мне кажется ты не хочешь понять суть проблемы. Давай на этом закончим.

true_admin ★★★★★
()

Предложи более внятное сообщение.

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

Да как же не об этом! Сообщение будет то, что указано в правилах.

~/sc_test$ scons
scons: Reading SConscript files ...
Checking for C function fdatasync()... no
You need fdatasync() to compile this program

~/sc_test$ cat SConstruct 
env = Environment()
conf = Configure(env)
if not conf.CheckFunc('fdatasync'):
    print('You need fdatasync() to compile this program')
    Exit(0)
env = conf.Finish()

а на самом деле

~/sc_test$ cat config.log 
...
gcc -o .sconf_temp/conftest_0.o -c .sconf_temp/conftest_0.c
gccx: error: npc: No such file or directory
gccx: fatal error: no input files
compilation terminated.
scons: Configure: no

Тут я намеренно испортил gcc, для примера. При сборке gcc такое бывает. Автотулы работают точно так же.

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

Отличный пример. Тут мы подошли к тому о чём я всё время говорю :).

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

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

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

Я ожидал что-то в духе «а зато configure умеет окружение проверять». Вот было бы интересно послушать мысли на тему на сколько это всё нужно.

Это просто нужно.

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

Это просто нужно.

В больших проектах я часто видел как при сборке этот configure запускается раз десять из различных мест. Уже одно это раздражает когда надо «что-то быстро собрать».

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

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

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

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

Хорошо хоть не предлагаешь мейкфайлы руками писать (хотя иногда этого достаточно).

Hjorn
()
Ответ на: комментарий от true_admin

Да и в чём смысл проверять окружение если при сборке в случае чего оно упадёт?

Странный вопрос. Ну, скажет тебе сборка «тип аргумента 5 функции foo не совпадает» - сравни это с «установлена версия libfoo 1.2.3, а нужна 1.2.4»; то же самое с тупо отсуствующими билиотеками; то же и с программами, поддерживающими разные среды сборки.

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

то же самое с тупо отсуствующими билиотеками; то же и с программами, поддерживающими разные среды сборки.

А я про это и не говорю ничего. Я говорю вот про то что кроме этого оно ещё кучу всякой фигни проверяет.

true_admin ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.