distcc между Intel и AMD

Ну так это вполне ожидаемо, раз у тебя там флаги разные. Если ты будешь запускать подобным образом собранный фаерфокс на интел проце(в котором естественно нет поддержки 3dnow) то он у тебя будет падать. Используй при кросскомпиляции такие CFLAGS чтоб оно было совместимо с тем процом, на котором этот фаерфокс планируется запускать

не догнал, если честно.
Я собираю Лису на Интел и для Интел, а на АМД для АМД. Т.е. я не использую один бинарник для обеих машин, каждая собирает свой. Distcc посылает на АМД, если АМД - сервер, а Интел - клиент, машину флаги интеловские, разве не так?

У тебя native для этих машин разные.

Ну если оно почему-то падает, то там там РАЗНЫЕ флаги. Подозреваю что раз ты передаешь -march=native -mtune=native то это значит что оно будет использовать эти флаги относительно того, на каком непосредственно процессоре происходит сборка. Т.е. на интеле оно собирает нативно под интел, а на амд оно собирает нативно под амд. этот native работает относительно того, где происходит компиляция

ну, это я понимаю. А вот к чему это ведёт - нет?

Это ведет к тому, что у тебя компилятор который собирает нативно под AMD вставляет туда инструкции, которых в Intel нету, и оно от этого падает.

я не передаю -march=native -mtune=native, а то, что указано 1-ом сообщении, т.е. -march=haswell/amdfam10 -mtune=haswell/amdfam10

да не нативно же, а вышеуказанные флаги, а там нет march/mtune=native.

Ну так у тебя на одном проце собирается под amdfam10, на другом под haswell. И ты потом это все смешиваешь. И где потом это запускать? На процессоре, который и Intel и AMD-специфичные инструкции поддерживает? Таких не существует в природе

разве серверу не передаются инструкции клиентской машины?
я думал, что distcc передает от клиента, например Интел, инструкции -march=haswell..., и на сервере, АМД, собирает также с -march=haswell..., не?

Ну так ты посмотри, с какими флагами у тебя этот distcc собирает там и там. Ты ж вот привел два набора флагов

Для AMD Phenom II X4 965;
для Intel i7-4770K:

И они отличаются. Получается что у тебя часть программы с одними флагами собирается, другая часть с другими, верно?

Получается что у тебя часть программы с одними флагами собирается, другая часть с другими, верно?

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

А как там у тебя происходит падение? SIGILL срабатывает, или просто какой-то сигфолт? Версии компиляторов одинаковые? Сравнить листинг ассемблера, выдаваемый при сборке одним и другим компилятором пробовал? Может быть там есть какие-то флаги по умолчанию, которые не перекрываются твоими флагами

CFLAGS="-march=amdfam10 -mmmx -m3dnow -msse -msse2 -msse3 -msse4a -mcx16 -msahf -mpopcnt -mabm -mlzcnt -mprfchw -mfxsr --param l1-cache-size=64 --param l1-cache-line-size=64 --param l2-cache-size=512 -mtune=amdfam10 -O2 -pipe -fomit-frame-pointer -fno-stack-protector"
MAKEOPTS="-j25 -l4"

На каком железе запускается собранный таким образом браузер?

А как там у тебя происходит падение?

заходишь на addons.mozilla.org, segmentation fault.
Да на обоих тачках так. Выяснил, что если собирать Лису с О1, то всё нормально. Васче нашёл такой же баг, решилось там также с О1, но там локалхост, но тоже интел задействован.
Короче, продолжу изыскания. А пока буду считать, что gcc-5.3 роняет Лису.

Сравни машинный код.

боюсь, а то начну сравнивать, портал ещё куда-нибудь откроется.

gcc-5.3 роняет Лису

Лису роняло системное cairo, сейчас уже нет, у меня вылечилось, и стабильно роняет cairo собранное с xlib-xcb. Попробуй собрать файрфокс без system-cairo. И конечно же без custom-cflags и custom-optimization. Сам по себе gcc-5.3 лису не роняет.

Для distcc, если у тебя кластер сборная солянка из процессоров разных поколений, набор флагов должен быть универсально консервативный (generic), тебе правильно говорят. Иначе у тебя кадавр соберётся, из кусков оптимизаций под разные процесоры с разными фичами и как это будет работать в итоге не ведомо никому и отлаживать это будет невозможно.

Так что march=x86-64 для начала, а дальше только те инструкции, которые точно есть у всего набора процов в твоём кластере.

Лиса и так без system-cairo.

Для distcc, если у тебя кластер сборная солянка из процессоров разных поколений, набор флагов должен быть универсально консервативный (generic), тебе правильно говорят. Иначе у тебя кадавр соберётся, из кусков оптимизаций под разные процесоры с разными фичами и как это будет работать в итоге не ведомо никому и отлаживать это будет невозможно.

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

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

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

По идее, в теории, действительно достаточно развернуть native для целевой машины в набор флагов и распихивать получившиеся по кластеру. По идее distcc ноде насрать как собирать. На практике же gcc проявляет какие то интеллектуальные попытки оптимизации, разные на разных нодах даже без native, и в итоге после линковки имеем нечто непредсказуемое. Гарантию работоспособности даёт только компиляция c march=x86_64 и прочим генериком, если у тебя зоопарк (а он у всех).

Так что distcc палка о двух концах - хочешь максимальной оптимизации используй native без distcc.

склонился к тому, что distcc хорош при начаальной установке Дженты, а потом проще перейти на march=native.
Притормаживаю distcc.