%general-entities; ]> gcc &gcc-version;
&gcc-url;
GCC-&gcc-version; GCC <para>Пакет GCC содержит коллекцию компиляторов GNU, которая включает компиляторы C и C++.</para> <segmentedlist> <segtitle>&buildtime;</segtitle> <segtitle>&diskspace;</segtitle> <seglistitem> <seg>&gcc-fin-sbu;</seg> <seg>&gcc-fin-du;</seg> </seglistitem> </segmentedlist> </sect2> <sect2 role="installation"> <title>Установка пакета GCC При сборке на x86_64 измените имя каталога по умолчанию для 64-битных библиотек на lib: case $(uname -m) in x86_64) sed -e '/m64=/s/lib64/lib/' \ -i.orig gcc/config/i386/t-linux64 ;; esac Документация GCC рекомендует собирать GCC в отдельном каталоге: mkdir -v build cd build Подготовьте GCC к компиляции: ../configure --prefix=/usr \ LD=ld \ --enable-languages=c,c++ \ --disable-multilib \ --disable-bootstrap \ --with-system-zlib Обратите внимание, что для поддержки других языков программирования существуют дополнительные условия, которые пока недоступны. См. страницу BLFS Book GCC для получения инструкций о том, как собрать все языки, поддерживаемые GCC Значение новых параметров настройки: LD=ld Этот параметр указывает скрипту configure использовать ld, установленный программой binutils, собранной ранее в этой главе, а не кросс версию, которая использовалась бы в противном случае. --with-system-zlib Этот параметр указывает GCC ссылаться на установленную в системе копию библиотеки zlib, а не на собственную внутреннюю копию. Скомпилируйте пакет: make В этом разделе набор тестов для GCC считается важным, но занимает много времени. Начинающим сборщикам не рекомендуется пропускать его. Время выполнения тестов можно значительно сократить, добавив -jx в приведенную ниже команду make, где x - количество ядер в вашей системе. Известно, что один набор тестов GCC исчерпывает стек по умолчанию, поэтому увеличьте размер стека перед запуском тестов: ulimit -s 32768 Выполните тестирование под непривилегированным пользователем, но не останавливайтесь на ошибках: chown -Rv tester . su tester -c "PATH=$PATH make -k check" Чтобы получить сводку результатов набора тестов, выполните: ../contrib/test_summary Чтобы получить только итоговую сводку, передайте выходные данные grep grep -A7 Summ. Результаты можно сравнить с результатами, размещенными на и . Известно, что в g++ четыре теста, относящиеся к PR100400, сообщают как XPASS, так и FAIL. Это потому, что тестовый файл написан не очень хорошо. Не всегда удается избежать неожиданных сбоев. Разработчики GCC обычно знают об этих проблемах, но еще не решили их. Если результаты теста не сильно отличаются от результатов по указанному выше URL-адресу, можно продолжать. Установите пакет: make install Каталог сборки GCC теперь принадлежит пользователю tester, и владелец на каталог (и его содержимое) указан неверно. Измените владельца на пользователя и группу root: chown -v -R root:root \ /usr/lib/gcc/$(gcc -dumpmachine)/&gcc-version;/include{,-fixed} Создайте символическую ссылку, требуемую FHS по "историческим" причинам. ln -svr /usr/bin/cpp /usr/lib Добавьте символическую ссылку совместимости, чтобы включить сборку программ с оптимизацией времени компоновки (LTO): ln -sfv ../../libexec/gcc/$(gcc -dumpmachine)/&gcc-version;/liblto_plugin.so \ /usr/lib/bfd-plugins/ Теперь, когда наш окончательный набор инструментов готов, важно еще раз убедиться, что компиляция и компоновка будут работать так, как ожидалось. Мы сделаем это, выполнив проверку работоспособности: echo 'int main(){}' > dummy.c cc dummy.c -v -Wl,--verbose &> dummy.log readelf -l a.out | grep ': /lib' Ошибок быть не должно, и вывод последней команды будет (с учетом платформо-зависимых различий в имени динамического компоновщика): [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] Теперь убедитесь, что мы настроили использование правильных стартовых файлов: grep -o '/usr/lib.*/crt[1in].*succeeded' dummy.log Вывод последней команды должен быть: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crt1.o succeeded /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crti.o succeeded /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/../../../../lib/crtn.o succeeded В зависимости от архитектуры вашего компьютера вышеуказанные параметры могут незначительно отличаться. Разница будет заключаться в имени каталога после /usr/lib/gcc. Здесь важно обратить внимание на то, что gcc нашел все три файла crt*.o в каталоге /usr/lib. Убедитесь, что компилятор ищет правильные заголовочные файлы: grep -B4 '^ /usr/include' dummy.log Эта команда должна вернуть следующий вывод: #include <...> search starts here: /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include /usr/local/include /usr/lib/gcc/x86_64-pc-linux-gnu/&gcc-version;/include-fixed /usr/include Опять же, имя каталога может отличаться от указанного выше, в зависимости от архитектуры вашей системы. Затем убедитесь, что новый компоновщик использует правильные пути поиска: grep 'SEARCH.*/usr/lib' dummy.log |sed 's|; |\n|g' Ссылки на пути, содержащие компоненты с '-linux-gnu', следует игнорировать, но в противном случае вывод последней команды должен быть таким: SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib64") SEARCH_DIR("/usr/local/lib64") SEARCH_DIR("/lib64") SEARCH_DIR("/usr/lib64") SEARCH_DIR("/usr/x86_64-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); 32-разрядная система может видеть несколько разных каталогов. Например, вот вывод с компьютера i686: SEARCH_DIR("/usr/i686-pc-linux-gnu/lib32") SEARCH_DIR("/usr/local/lib32") SEARCH_DIR("/lib32") SEARCH_DIR("/usr/lib32") SEARCH_DIR("/usr/i686-pc-linux-gnu/lib") SEARCH_DIR("/usr/local/lib") SEARCH_DIR("/lib") SEARCH_DIR("/usr/lib"); Затем убедитесь, что мы используем правильную libc: grep "/lib.*/libc.so.6 " dummy.log Вывод последней команды должен быть: attempt to open /usr/lib/libc.so.6 succeeded Убедитесь, что GCC использует правильный динамический компоновщик: grep found dummy.log Вывод последней команды должен быть (с учетом различий в имени динамического компоновщика, зависящих от платформы): found ld-linux-x86-64.so.2 at /usr/lib/ld-linux-x86-64.so.2 Если вывод выглядит не так, как показано выше, или вообще не получен, значит, где-то серьезная ошибка. Изучите и повторите шаги, чтобы выяснить, в чем проблема, и исправьте ее. Любые проблемы должны быть решены, прежде чем вы продолжите процесс. Как только все заработает правильно, удалите тестовые файлы: rm -v dummy.c a.out dummy.log Наконец, переместите файл: mkdir -pv /usr/share/gdb/auto-load/usr/lib mv -v /usr/lib/*gdb.py /usr/share/gdb/auto-load/usr/lib Содержимое пакета GCC Установленные программы Установленные библиотеки Созданные каталоги c++, cc (link to gcc), cpp, g++, gcc, gcc-ar, gcc-nm, gcc-ranlib, gcov, gcov-dump, gcov-tool, и lto-dump libasan.{a,so}, libatomic.{a,so}, libcc1.so, libgcc.a, libgcc_eh.a, libgcc_s.so, libgcov.a, libgomp.{a,so}, libitm.{a,so}, liblsan.{a,so}, liblto_plugin.so, libquadmath.{a,so}, libssp.{a,so}, libssp_nonshared.a, libstdc++.{a,so}, libstdc++fs.a, libsupc++.a, libtsan.{a,so}, и libubsan.{a,so} /usr/include/c++, /usr/lib/gcc, /usr/libexec/gcc, и /usr/share/gcc-&gcc-version; Краткое описание c++ Компилятор С++ c++ cc Компилятор C cc cpp Препроцессор C; он используется компилятором для расширения инструкций #include, #define и аналогичных инструкций в исходных файлах cpp g++ Компилятор C++ g++ gcc Компилятор C gcc gcc-ar Обертка над ar, добавляющая плагин в командную строку. Эта программа используется только для добавления "оптимизации времени компоновки" и бесполезна с параметрами сборки по умолчанию. gc-ar gcc-nm Обертка над nm, добавляющая плагин в командную строку. Эта программа используется только для добавления "оптимизации времени компоновки" и бесполезна с параметрами сборки по умолчанию. gc-nm gcc-ranlib Обертка над ranlib, добавляющая плагин в командную строку. Эта программа используется только для добавления "оптимизации времени компоновки" и бесполезна с параметрами сборки по умолчанию. gc-ranlib gcov Инструмент тестирования; он используется для анализа программ, чтобы определить, где оптимизация будет иметь наибольший эффект. gcov gcov-dump Автономный инструмент для дампа профилей gcda and gcno gcov-dump gcov-tool Автономный инструмент обработки профиля gcda gcov-tool lto-dump Инструмент для создания дампа объектных файлов, созданных GCC с включенным LTO. lto-dump libasan Библиотека времени выполнения Address Sanitizer libasan libatomic Встроенная библиотека времени выполнения GCC atomic libatomic libcc1 Библиотека предварительной обработки C libcc1 libgcc Содержит средства поддержки времени исполнения для gcc libgcc libgcov Эта библиотека компонуется с программой, когда для GCC указано использовать профилирование libgcov libgomp GNU реализация интерфейса OpenMP API мультиплатформенного параллельного программирования для языков C/C++ и Fortran с общим доступом к памяти libgomp libitm Библиотека транзакционной памяти GNU libitm liblsan Библиотека времени выполнения Leak Sanitizer (средств защиты от утечек) liblsan liblto_plugin Плагин GCC LTO позволяет binutils обрабатывать объектные файлы, созданные GCC с включенным LTO. liblto_plugin libquadmath API математической библиотеки GCC Quad Precision libquadmath libssp Содержит подпрограммы, поддерживающие функциональность защиты стека GCC. libssp libstdc++ Стандартная библиотека C++ libstdc++ libstdc++fs Библиотека файловой системы ISO/IEC TS 18822:2015 libstdc++fs libsupc++ Предоставляет вспомогательные процедуры для языка программирования C++ libsupc++ libtsan Библиотека времени выполнения Thread Sanitizer (средств очистки потоков) libtsan libubsan Библиотека времени выполнения Undefined Behavior Sanitizer (средств очистки неопределенного поведения) libubsan