Ошибка не воспроизводится, поэтому, скорее всего, это проблема оборудования или ОС [закрыто]
Я пытаюсь установить Samba 4.0.9 на один сервер, но все время получаю это ошибка каждый раз. Я перепробовал все, от apt-get -f install до редактирования / var / lib / dpkg / status Пакет: Samba4 Установить нормально установлено
Это ошибка, которую я получаю:
[ 866/3792] Compiling source4/dsdb/common/util.c
[ 867/3792] Compiling source4/dsdb/common/util_groups.c
In file included from ../lib/replace/system/time.h:30:0,
from ../source4/include/includes.h:33,
from ../source4/dsdb/common/util_groups.c:22:
/usr/include/i386-linux-gnu/sys/time.h:61:3: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.6/README.Bugs> for instructions.
The bug is not reproducible, so it is likely a hardware or OS problem.
Waf: Leaving directory `/samba/bin'
Build failed: -> task failed (err #1):
{task: cc util_groups.c -> util_groups_6.o}
make: *** [all] Error 1
Если потребуется дополнительная информация, я предоставлю ее вам. Заранее спасибо.
2 ответа
Когда debian gcc обнаруживает внутреннюю ошибку, он снова пытается запустить код через ядро компиляции. Если он получает одинаковые результаты каждый раз, когда полагает, что это действительно ошибка в ядре компилятора. Если этого не произойдет, вы получите «Ошибка не воспроизводима, поэтому, скорее всего, это проблема аппаратного или ОС». сообщение.
Это может быть вызвано ошибкой в ядре компилятора, которая чувствительна к какому-то внешнему фактору, ошибкой в ядре или хитрым оборудованием.
Вы также можете увидеть это сообщение, если вы запускаете систему сборки, которая выполняет несколько шагов сборки параллельно на многоядерном компьютере, и один из этих шагов требует вывода от другого, но система сборки не знает его .
Например:
-
step1: генерировать файл заголовка, который будет использоваться на шаге 2
-
step2: запустить gcc для компиляции .c файл, содержащий заголовок из шага 1.
Если система сборки не знает, что шаг 2 зависит от выходных данных шага 1, то она может попытаться воспользоваться тем фактом, что ей доступно несколько ядер ЦП, и выполнить оба шага одновременно , В этом случае step2 завершится с ошибкой, поскольку необходимый ему заголовочный файл еще не создан. В случае сбоя gcc повторяет компиляцию, но к этому моменту шаг 1 завершен и файл заголовка доступен. Итак, вторая попытка успешна, и gcc предполагает, что противоречивые результаты означают, что ОС или аппаратное обеспечение каким-то образом выходит из строя, даже если они функционируют отлично.
Это хороший пример многопоточного состояния гонки, которое может оказаться весьма непредсказуемым, если его встретить в более сложных сценариях (таких как система сборки большого проекта, такого как Samba).
Я испытал это лично, используя систему сборки ниндзя в другом проекте.
Способ исправить это - убедиться, что ваши сценарии сборки информируют систему сборки о зависимости между шагами.