Ubuntu 12 ломает сборку gcc 4.7 из исходного кода

Я широко использую C ++ 11, поэтому сразу после установки новой версии Xubuntu 12.04 LTS я начал собирать gcc из исходного кода. После получения необходимых зависимостей с помощью sudo apt-get build-dep gcc-4.7-base я проверил тег 4.7.0 gcc в Subversion и начал его строить.

На моем 64-битном ноутбуке сборка (настроенная с --disable-multilib --enable-libstdcxx-time=rt --enable-languages=c,c++) не смогла найти файлы, связанные с libc6-dev, несмотря на то, что этот пакет был установлен. Я смог исправить проблемы, просто соединив / usr / lib64 с / usr / lib / x86_64-linux-gnu по предложению поста StackOverflow. После этого сборка gcc прошла успешно и, похоже, после установки работает нормально.

Моя 32-битная настольная система была другой историей. У меня была та же самая начальная проблема, когда файлы libc6-dev не могли быть найдены цепочкой сборки gcc. В конце концов мне пришлось экспортировать следующие переменные окружения для правильной сборки (идея взята из здесь ):

export LIBRARY_PATH=/usr/lib/i386-linux-gnu/
export C_INCLUDE_PATH=/usr/include/i386-linux-gnu
export CPLUS_INCLUDE_PATH=/usr/include/i386-linux-gnu

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

Хмм, sed очень пессимистично относится к файлам заголовков вашей системы. Но это не дамп ядра - странно! Давайте продолжим осторожно ... Если это не удастся, вы можете удалить ошибочные строки из osdef.h или попробовать с пустым файлом osdef.h, если ваш компилятор может обойтись без объявлений функций.

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

Может ли кто-нибудь пролить свет на это?

2
задан 1 May 2012 в 04:22

1 ответ

Как я сказал в своем комментарии, проблема не в ошибке в GCC или Ubuntu, а в несовместимости: multiarch . Смысл multiarch заключается в том, чтобы позволить двоичным файлам для нескольких архитектур быть установленными в одной и той же файловой системе в одно и то же время без коллизий. Это заменит старую систему 32-битных и 64-битных библиотек, которая раньше существовала, но это действительно более важно, когда мы хотим, например, установить Intel и ARM одновременно. Предположительно, это не очень интересно для настольных компьютеров, но Ubuntu существует во многих встроенных устройствах (или сделает), которые могут делать подобные вещи.

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

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

amd64 (я тестировал этот):

sudo -i
# apt-get install libppl0.11-dev libmpfr-dev libgmp-dev libc6-dev-i386
# cd /usr/include
# ln -s x86_64-linux-gnu/* .
# cd /usr/lib
# ln -s x86_64-linux-gnu/crt* .

Я вижу тебя » использую 32-битную Ubuntu. Я не проверял это, но я сделал очевидные изменения.

ix86:

sudo -i
# apt-get install libppl0.11-dev libmpfr-dev libgmp-dev libc6-dev
# cd /usr/include
# ln -s i386-linux-gnu/* .
# cd /usr/lib
# ln -s i386-linux-gnu/crt* .

ВНИМАНИЕ: вставка программных ссылок обычно безвредна для большинства людей, но вполне может вызвать проблемы в дальнейшем. , (В основном, только если вы хотите создавать как 64-битные, так и 32-битные проекты на одном компьютере.)

0
ответ дан 1 May 2012 в 04:22

Другие вопросы по тегам:

Похожие вопросы: