Я широко использую 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, если ваш компилятор может обойтись без объявлений функций.
blockquote>Когда я перенес эту историю о рыданиях на IRC-канал gcc, несколько человек там выразили разочарование в Ubuntu и сказали мне, что эти ошибки были вызваны тем, что Ubuntu 12 изменил давние пути к файлам.
Может ли кто-нибудь пролить свет на это?
Как я сказал в своем комментарии, проблема не в ошибке в 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-битные проекты на одном компьютере.)