«кривая сборка» - это каг?

Ну это надо спросить у мейнтейнеров кде в убунте. Так как на дебиане оно "just works", и примерно так же "just works" на той же убунте, если собрать ванилу, а вот версии из пакетов падучи как незнамо что.

Сборка криво собранным компилятором, под другое ядро, етс.

1. Исходные коды не всегда одинаковые - ибо дистры в разное время выходят.
2. ./configure --with-buggy-lib и ./configure --without-buggy-lib несколько разный эффект дадут.
3. Еггоги в зависимостях.

>Сборка криво собранным компилятором, под другое ядро, етс.

GCC-4.3.2, собранный с -O3 -march=core2 собирал нормально. Думаю, это от "сборки" компилятора не зависит.

Под ядро собрать нельзя. Если ты про хидеры ядра - то мало какая софтина их вообще использует.

>>1. Исходные коды не всегда одинаковые - ибо дистры в разное время выходят.

Не, я о том случаи когда используются пакеты с одной и той же версий софта/либы/etc.

>>2. ./configure --with-buggy-lib и ./configure --without-buggy-lib несколько разный эффект дадут.

ну это да...

Свежий пример: в кубунтовском долфине не работало "вырезать"

Чёрт! Такой бред написал, а сервак полёг, и история тоже ;(

Мэйнтейнеры многих дистров накладывают на исходники патчи, исправляя некоторые известные баги.

+ к этому, собирают с разными опциями компилятора и вообще, разным версиями компилятора и под разное системное окружение.

Номер адин: патчи.

Никогда не видел таких патчей, что влияют на стабильность больших программ. Глюки, падения, дыры обычно закрываются в минорных релизах. Это всё о десктопах, основано на моих наблюдениях.

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

Номер два: зависимости.

Хочется чтобы пользователю предоставлялось больше функционала. Да. Правда не всем это надо, но всем и не угодишь :) Что из этого может быть?

Можно посмотреть на KDE-3.5.x :) Я ещё не видел дистриба, где он не потянул бы за собой Avahi(вроде хорошая штука, только не знаю где использовать) и GTK+(требуется для librsvg). Всё это зависимости...

Можно представить как Avahi-daemon не запускается, или какой-то другой мэйнтэйнер обновил Pango/GTK+ - перевёл на новую ветку, к примеру. И, внезапно, что-то заглючило. Причём мэйнтейнеров KDE не сильно это касается - проблема совсем в другом пакете.

Слишком большое количество пакетов, всё нужно тестировать...

Да, сборщики пакетов хорошо тестируют, пытаются предоставить максимум стабильности, функциональности и производительности... Вроде даже принимают решения вместе. Однако это не мешает иногда вылазить ошибкам.

Номер три: флаги.

Оптимизация под один тип процессора - роскошь. Мало где такое увидишь. Дистр должен работать на куче железа. Тут нельзя позволить себе поставить -O2 -march=<что-то> и радоваться. Некоторые даже заботятся о пользователе, и включаюст SSP - Stack Samshing Protection. А ещё некоторые слишком хотят покрыть падение её из-за поддержки кучи архитектур и ставят -fomit-frame-pointer.

Забота - это хорошо. Но криворукие убунт^W сборщики для убунты умудряются(замечено в одной программе в Убунту-7.04) запихать -march=i486 -mtune=i686 -O2 -fomit-frame-pointer -funroll-loops -fstack-protector-all и, самое главное, "-g " - отладочные символы. Я даже боялся смотреть на LDFLAGS, как на исходники винды...

Эти милые люди мало того что лишили нас всех прелестей процов выше pentium3 и запихали "ускорители" в виде "fomit-frame-pointer -funroll-loops", от которых у меня очень часто всё глючило, так ещё и засунули заищту от переполнения - SSP.

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

Я понимаю, что Splint - слишком много для обычного дистриба. Но тестировать нужно.

Всё это было с программой просмотра картинок. Сейчас в Убунте этого глюка нет, но флаги такие-же идиотские. _______________________

3 года пользовался LFS, думаю, я могу рассуждать о "правильности" сборки. Поэтому написал этот поток бредовых мыслей.

То, что сверху - ИМХО. Если где ошибся - скажите. Подумаю. ;)

>самое главное, "-g " - отладочные символы

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

Более того, эти -g обычно складываются в отдельный пакет, *-dbg

Спасибо, знаю.

Это не помешало быть таким бинарникам в обычном пакете. ;)

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

Таки есть вменяемые люди на сайте :) Я догадаывался о подобных нюансах в GCC, но т.к. с сями дела не имею, то в подробности не вдавался особо. Но вообще еще ожидал мнения фанатиков, которые о кривостях только вопят, как о "нужно/ненужно":)

>Таки есть вменяемые люди на сайте :) Я догадаывался о подобных нюансах в GCC, но т.к. с сями дела не имею, то в подробности не вдавался особо.

Это про меня, или adarovsky?

/ме - больной параноик. Справки нет - не дают.

>>Это про меня, или adarovsky? /ме - больной параноик.

Ну, ответ был адресован тебе, а больной или не больной, то это по другой части. Я в том плане, что ты обосновал ответ :)

>Мэйнтейнеры многих дистров накладывают на исходники патчи, исправляя некоторые известные баги.

И внося некоторые неизвестные ;)