Как обновить gcc mac os

Обновлено: 06.07.2024

Итак, я новый программист и только что установил XCode на свой Macbook, чтобы получить GCC. Я думаю, что Xcode-это единственный способ получить GCC на OSX. Теперь, когда я запускаю свое приложение Hello World в C++, g++ говорит, что это версия 4.0.1, но когда я ищу команды, начинающиеся с g, я также вижу g++-4.2. Есть ли способ сделать 4.2 по умолчанию, а не 4.0.1, а также есть ли способ обновить gcc до последней версии 4.4.0?

EDIT: хорошо, Итак, я установил macports и установил gcc4.4, и он отображается на terminal как gcc-mp-4.4, и как мне сделать его по умолчанию с помощью gcc_select, например, какие команды и прочее. Спасибо.

Всего пару дней назад я обнаружил и использовал OSX-GCC-Installer Кеннета Рейца , чтобы решить проблему установки Ruby 1.9.3 через RVM на мой Mac. Сегодня я прочитал в блоге Кеннета о пакете инструментов командной строки для Xcode , который Apple только вчера добавила в свой официальный набор.

Я новичок в OSX. Когда я открываю terminal, у меня нет make или gcc ; однако я установил xcode , так что из того, что я прочитал, они должны быть где-то на OS. Что же мне делать?

Если вы устанавливаете macports, вы можете установить gcc select, а затем выбрать версию gcc.

Чтобы увидеть ваши версии, используйте

Для выбора версии используйте

Я знаю, что это старая просьба. Но для некоторых это все еще может быть полезно. С текущими версиями MacPorts вы можете выбрать версию gcc по умолчанию с помощью команды port. Чтобы перечислить доступные версии gcc, используйте:

Чтобы установить gcc в версию MacPorts:

$ sudo выбор порта --установить gcc mp-gcc46

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

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

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

Более того, это не гарантирует, что это сработает - в частности, неясно, получите ли вы правильные системные файлы, которые, безусловно, изменились между итерациями gcc.

К сожалению :-( gcc_select не влияет на то, какой компилятор использует XCode, поэтому это не тот путь, если вам нужно работать в XCode (что я и делаю). Я до сих пор не знаю, что это может быть за путь.

Следующий рецепт с использованием Homebrew работал для меня, чтобы обновить его до gcc/g++ 4.7:

Нашел его на столбе здесь .

использовать "gcc_select -l"

> gcc_select -l

gcc40 mp-gcc44

> gcc_select mp-gcc44

sudo ln -s -f g++-4.2 g++

sudo ln -s -f gcc-4.2 gcc

Этого должно хватить.

У вас может быть несколько версий GCC в вашем поле, чтобы выбрать ту, которую вы хотите использовать, вызовите ее с полным путем, например, вместо g++ используйте полный путь /usr/bin/g++ в командной строке (зависит от того, где живет ваш gcc).

Для компиляции проектов это зависит от того, какую систему вы используете, я не уверен насчет Xcode (я доволен atm по умолчанию), Но когда вы используете Makefiles, вы можете установить GXX=/usr/bin/g++ и так далее.

Теперь есть скрипт xcrun , который можно запросить, чтобы выбрать соответствующую версию инструментов сборки на mac. Помимо man xcrun я погуглил это объяснение о xcode и инструментах командной строки , которые в значительной степени обобщают, как его использовать.

При запуске rbenv install 1.9.2-p320 я получаю следующий вывод: ERROR: этот пакет должен быть скомпилирован с GCC, но ruby-build не смог найти подходящий исполняемый файл gcc в вашей системе. Пожалуйста, установите GCC и повторите попытку. DETAILS: Apple больше не включает официальный компилятор.

Я думаю, что у меня есть несколько версий gcc, установленных на моем Mac OSX. Прямо сейчас, когда я набираю gcc --version. Я получил gcc (GCC) 4.6.0 20100703 (экспериментальный) . Но я хочу использовать более раннюю версию gcc. Дело в том, что я не знаю, как найти путь к более старой версии gcc.

Вы можете установить свой GCC вручную

или вы скачиваете исходный код с одного из зеркал отсюда например здесь

tar xzvf gcc-4.6.0.tar.gz компакт gcc-4.6.0 ./настроить сделать

ну а если у вас есть несколько версий, то через них вы можете выбрать одну

Все, что Apple поставляет по умолчанию gcc в xcode (4.2.1 на 10.6, 4.0.1 раньше), хорошо протестировано (и поддерживается) ребятами из Apple и "standard" для создания программного обеспечения в OS X. Все остальное не так, поэтому подумайте дважды, если вы хотите разрабатывать программное обеспечение или быть бета-тестером gcc/OS X.

3 ответа

Сборка GCC в Mac OS X - иногда трудоемкий процесс. У меня были различные проблемы с различными версиями GCC и различными версиями Mac OS X на протяжении многих лет. Вы можете увидеть более раннее объяснение того, что я сделал, в Установите GCC в Mac OS X - это было для сборки GCC 4.8.x на Mavericks 10.9.x (или, возможно, Mountain Lion 10.8.x); он также сообщает об успешном построении GCC 4.9.0 на Mavericks 10.9.x, но об отказе сделать это на Yosemite 10.10.x.

Это обновленный рецепт сборки GCC 5.2.0 на Mac OS X 10.11.1 El Capitan. Он начинается с использования XCode 7.1.1 - я не знаю, какие другие версии XCode подходят.

Обратите внимание, что El Capitan имеет функцию SIP (Защита целостности системы), которой не было в Yosemite и более ранних версиях. Это означает, что вы больше не можете создавать произвольные каталоги в /usr . Раньше я устанавливал в /usr/gcc/vX.Y.Z ; это больше не разрешено в Эль-Капитане. Поэтому одним из основных изменений является то, что теперь я устанавливаю в /opt/gcc/v.X.Y.Z .

Я обнаружил, что установить DYLD_LIBRARY_PATH проблематично, особенно на El Capitan. В отличие от прошлого, я сейчас вообще не устанавливаю это. Обратите внимание, что скрипты отключили его. Также обратите внимание, что сценарий явно устанавливает для компиляторов фазы 1 CC и CXX значения /usr/bin/clang и /usr/bin/clang++ соответственно (компиляторы XCode). Текущие версии GCC требуют наличия совместимого компилятора C ++ вместо (или не хуже) компилятора C.

Иногда у меня возникали проблемы с libiconv , но на данный момент я их избегаю, так как не установил свою собственную версию. Точно так же у меня иногда возникали проблемы с некоторыми сценариями awk в исходном коде GCC. Мне пришлось взломать его / их, чтобы заставить его работать нормально. Однако с релизной копией исходного кода GCC 5.2.0 я, кажется, могу собирать прямо из коробки.

Если у вас только один раздел диска, следующий пункт не имеет решающего значения. Если у вас несколько дисков, либо убедитесь, что целевой каталог не существует, либо убедитесь, что его имя соответствует вашему желанию. На работающих машинах (не Mac, а Linux и т. Д.) Я все еще использую /usr/gcc/vX.Y.Z в качестве "официального" места установки, но программа попадает в произвольную файловую систему, в которой достаточно места, например >, и, в конце концов, существует символическая ссылка, такая, что /usr/gcc/vX.Y.Z попадает в /work4/gcc/vX.Y.Z . Однако крайне важно, чтобы /work4/gcc/vX.Y.Z не существовал во время компиляции GCC, потому что он разрешит имя через realpath() или его эквивалент и вставьте /work4/gcc/vX.Y.Z в двоичные файлы, а не нейтральное имя /usr/gcc/vX.Y.Z . Это ограничивает портативность установки; любая другая машина, на которую он перемещается, должна иметь каталог /work4/gcc/vX.Y.Z , даже если вы просили установить его в /usr/gcc/vX.Y.Z .

Компиляция GCC 5.2.0 в Mac OS X 10.11.1 с XCode 7.1.1

Пришлось работать с даун-версиями как GMP (5.1.3 вместо 6.0.0a), так и ISL (0.14 вместо 0.15). Обе сборки для более поздних версий вызвали у меня проблемы.

Обратите внимание, что я поместил код библиотеки для GMP, MPC, MPFR, ISL и Cloog (см. GCC pre- реквизиты) в исходном каталоге GCC, чтобы GCC создавал свои собственные версии этих библиотек. Я обнаружил, что это самый простой способ убедиться, что GCC правильно размещает эти библиотеки.

Целевой каталог: /opt/gcc/v5.2.0

Время сборки составило около 2 часов 15 минут на MacBook Pro 17 дюймов (начало 2011 г.) с процессором Intel Core i7 с тактовой частотой 2,3 ГГц, с 16 ГиБ основной памяти DDR3 1333 МГц и жестким диском на 750 ГБ, 5400 об / мин. Исходный код занимает около 850 МБ; размер дерева сборки составляет около 4,6 ГиБ - вам нужно много места на диске. Размер установленного кода составляет около 420 МБ.

Используемый скрипт - extract-gcc-5.2.0.sh

Скрипт nbncl - непустые строки без комментариев

Как бы то ни было, у MacPorts есть порты для всех последних версий, которые должны быть достаточно простыми для чтения всем (кто умеет кодировать!), Кто не хочет устанавливать MacPorts, но предпочитает устанавливать различные зависимости, упомянутые здесь, другим способом.

Причина, по которой я упоминаю это (и опубликую этот ответ), заключается в том, что эта измененная версия показывает, как заставить G ++ использовать libc ++ вместо libstdc ++. Это прерогатива использования G ++ в качестве реальной замены clang ++, который можно использовать, не беспокоясь о несовместимости времени выполнения C ++. Этот патч позволил мне использовать g ++ для сборки кода KDE (KF5) и запустить его на Qt5 и фреймворках KF5, созданных с помощью различных версий компилятора clang. (Файлы патча находятся в . / gcc6 / files.)

Некоторое объяснение, которое может помочь интерпретировать Tcl-код связанного файла:

Игнорируйте все, что относится к $ subport == "libgcc".

Как видите, вам нужны gmp, mpc, mpfr и isl (другие зависимости не должны представлять интереса, если вы устанавливаете самостоятельно).

Выражения configure.args создают список аргументов для сценария configure, configure.env и build.env добавляют переменные среды для команд configure и build (make). Многие из параметров настройки здесь предназначены для того, чтобы гарантировать, что сборка использует зависимости от MacPorts, но они, вероятно, также потребуются, если вы хотите или должны использовать местоположение, не контролируемое SIP и не включенное в стандартные определения PATH (компилятор все еще должен работать при вызове через процесс, сбрасывающий путь).

Настройка и сборка выполняются в каталоге сборки, который находится рядом с исходным каталогом, что позволяет очень легко начать заново или просто очистить, не выбрасывая исходные коды. После этапа настройки сборка выполняется с помощью команды make bootstrap-lean, которая по-прежнему создает около 1,7 ГБ данных в этом каталоге сборки.

Во-первых, см. Очень полный ответ Джонатана Леффлера. У меня есть еще несколько предложений.

Процесс настройки и сборки gcc должен найти собственные файлы заголовков вашей системы и библиотеки времени выполнения C. Новые, основанные на clang версии Xcode скрывают это довольно глубоко, а более старые версии gcc, похоже, не знают, как их найти. Чтобы вообще собрать gcc 4.6, мне пришлось создать следующие символические ссылки:

Ваш пробег, скорее всего, будет немного отличаться: обратите внимание, что имена путей под /Applications/Xcode.app/Contents имеют различные номера версий, которые могут отличаться в вашей системе.

(Если, как описывает Джонатан, новейшие версии MacOS не позволяют вам помещать что-либо в /usr , вам, возможно, придется вместо этого создать символическую ссылку /usr/include в /usr/local/include , и я подозреваю, что это тоже сработает.)

Кроме того, это упоминается в другом месте, но это необычное требование, которое легко упустить из виду: не пытайтесь собрать gcc в его собственном дереве исходного кода . Всегда создавайте каталог сборки, который является параллельным родственником , а не дочерним по отношению к каталогу, в который вы извлекли исходные коды gcc. То есть не этого:

Вместо этого сделайте следующее:

Я знаю, что это противоречит здравому смыслу, и это не так, как работают многие другие пакеты, но это определенно работает для gcc, и это рекомендуемый способ сделать это.

Еще один момент: если вы обнаружите, что ваша сборка не работает из-за того, что вы ее неправильно настроили, так что вам нужно повторно запустить configure с другими параметрами, безопаснее удалить весь каталог сборки и начать с нуля. Система настройки и сборки иногда, но кажется не на 100% надежной, обнаруживает, что в этом случае может потребоваться перестройка. (Я согласен, что удаление и запуск заново - это разочарование, но, опять же, это действительно может сэкономить время в долгосрочной перспективе.)

Наконец, если вы пытаетесь создать кросс-компилятор, ознакомьтесь с некоторыми дополнительными предложениями и комментариями по адресу установить gcc 4.6.1 в OS X 10.11.

Заинтригованный впечатляющими бенчмарками M1, я достал последний Mac Mini, чтобы замерить скорость компиляции на C/C++.

Измеряем локальный build2 (без репозитория пакетов), который включает преимущественно код на C++ (611 единиц трансляции) с некоторыми блоками на C (29) и связками между ними (19). Такой бенчмарк требует только компилятора C++ и входит в тестовый набор Phoronix, поэтому можно сравниться с большим количеством процессоров.

Бенчмарк Phoronix в настоящее время использует build2 0.12.0, у нас 0.13.0 (текущий релиз), здесь сборка выполняется примерно на 10% медленнее.

После настройки Mac OS и установки инструментов командной строки для XCode 12.2 у нас есть всё необходимое:

Судя по _LIBCPP_VERSION в заголовке __version файла libc++ , эта версия Apple Clang ответвилась от ванильного Clang где-то в процессе разработки 10.0.0.

Возможно, вы также заметили, что название процессора в триплете Apple Clang отличается от стандартного aarch64 . На самом деле config.guess показывает следующее:

Чтобы не использовать два названия для одного и того же, build2 канонизировал arm64 в aarch64 , поэтому в buildfiles мы всегда видим aarch64.

Проверим количество аппаратных потоков в sysctl :

Здесь 8 потоков, это 4 производительных ядра и 4 энергоэффективных. В первом прогоне задействуем все ядра. Очевидно, это даёт наилучший результат:

Приятным сюрпризом оказалось то, что build2 0.13.0 заработал без особых проблем, хотя он вышел раньше M1. Поскольку в ARM слабое упорядочение памяти, это также послужило дополнительной проверкой многопоточной реализации build2 и интенсивного использования атомиков.

Однопоточный бенчмарк оценивает производительность CPU в инкрементальных билдах:

Ядро E-2288G справляется за 826 секунд. Таким образом, ядро Xeon на 5 ГГц на самом деле медленнее, чем ядро M1 на 3,2 ГГц.

Еще один интересный результат — четырёхпоточный прогон, который использует только производительные ядра М1:

Хотя он несколько медленнее восьмиядерного теста, но зато использует меньше памяти. Таким образом, такой вариант имеет смысл на системах с недостатком оперативной памяти (как на всех современных машинах M1).

Вот краткое изложение всех результатов:

Понятно, что во многих отношениях это сравнение яблок с апельсинами (рабочая станция против мобильного устройства, старый дизайн и техпроцесс против самого современного и т. д.)

Теперь добавим несколько интересных результатов из бенчмарка Phoronix. В частности, уместно взять показатели новейших рабочих станций и мобильных процессоров Intel и AMD. Вот моя подборка (можете составить собственную, только не забудьте добавить дополнительные 10% к результатам Phoronix; также обратите внимание, что в большинстве тестов используется GCC вместо Clang):

Обратите внимание, что результаты для лучших мобильных Intel (1185G) и AMD (4900HS), к сожалению, ещё не доступны, и приведённые цифры экстраполированы на основе частоты и других бенчмарков.

Из приведённой выше таблицы легко понять, что Apple M1 — впечатляющий процессор, особенно с учётом энергопотребления. Более того, это первый общедоступный ARM-процессор настольного класса. Для сравнения, та же сборка на Raspberry Pi 4B занимает 1724 секунды, то есть более чем в 10 раз медленнее! Хотя мы не можем тут загрузить Linux или Windows, но есть некоторые свидетельства, что они работают на виртуальных машинах с приличной производительностью. В итоге, конвейер непрерывной сборки на базе ARM может стать стандартным.

Увидев бенчмарки M1, невольно задаёшься вопросом, как Apple такое удалось. Хотя есть много спекуляций с некоторыми элементами чёрной магии и колдовства, но вполне хорошим источником технической информации мне показалась эта статья о M1 на Anandtech (и ещё одна там по ссылке). Основные моменты:

Процесс TSMC 5 нм
По сравнению с интеловскими 10 нм (для 11x5G, 14 нм для E-2288G) и 7 нм у AMD/TSMC.

LPDDR4-4266 RAM
Только новейшие мобильные процессоры от Intel и AMD работают с такой быстрой памятью.

Большой кэш L1
У M1 необычно большой кэш L1 для команд и данных.

Большой и быстрый общий кэш L2
В отличие от процессоров Intel и AMD, которые используют отдельные кэши L2 меньшего объёма и большой, но более медленный общий кэш L3, в процессоре M1 реализован быстрый и большой общий кэш L2.

Широкое ядро
У M1 необычайно «широкое» ядро, которое выполняет несколько инструкций параллельно и/или не по порядку. Есть предположение, что из-за слабого упорядочения памяти ARM и кодирования команд фиксированного размера, Apple смогла сделать гораздо более широкое ядро.

Казалось бы совсем не давно наличие самостоятельно собранного PC считалось нормой высоких технологий, а постоянный «апгрейд» доставлял игровое удовольствие — как процесс творчества. Да и чувствовалась какая-то законченность, так как если не PC — то что? В то прекрасное время, как правило, все PC имели настоящие COM и LPT порты, что упрощало «до нельзя» изучение и освоение AVR. Чем, собственно многие и баловались. Ну как не побаловаться? PC — вот он под рукой, купил AVR-ку «за не дорого» и шей её сколько душе угодно, «скрутив» один единственный шнурок :))

Но, как известно — «всё течёт, всё меняется», и стала появляться достойная (в аппаратном смысле) техника, которая не шумит, собрана «по белому», работает по 24 часа в сутки годами и не виснет, и не греется. И стала находить она своё распространение среди честного люда. И стал чаще возникать вопрос перед честным людом как на сим коне ещё и свои AVR-прихоти реализовывать, учитывая то, что аппаратных COM и LPT портов нет. Да и система несколько отличается — Mac OS X как-никак :) Не ставить же ради AVR дополнительно ОС Windows?

Вот и решил автор облегчить начинающим жизнь, поделившись своим опытом. Описание действительно и будет полезно для обладателей iMac, Mac Mini под управлением Mac OS X (Snow Leopard).

Необходимое ПО.

Итак. Mac OS кроме графического интерфейса имеет прекрасную Unix-like оболочку. Люди, которые раньше сталкивались с Linux, Unix и прочими *nix системами, будут прекрасно себя чувствовать, используя наработки всего *nix мира, которые прекрасно живут и здесь. Да и для тех, кто не сталкивался с *nix системами — ничего страшного. Так как из всей мощи коммандной строки, нам, вобщем-то, необходимо будет всего-то: запускать комманду компиляции, да и утилиту прошивки AVR устройст. Проще говоря, всё у нас сведётся к двум коммандам: make и make flash :)

Теперь открываем программу «Терминал» (если Терминал был открыт, желательно открыть новое окно, чтобы появились новые переменные окружения). Заходим в любимый каталог, где мы собираемся творить свои поделки, например это будет рабочий стол. Для этого в «Терминале», в коммандной строке пишем:
cd

Теперь мы в каталоге рабочего стола. Создадим здесь Demo проект, для чего введём:
avr-project Demo

Main.c — собственно сама программа для AVR.
Makefile — а это самый нужный файл, к которому нужно очень внимательно отнестись в самом начале настройки. Так как в нём мы укажем для какого процессора компилировать программу, параметры прошивания устройства и т. д. Это сделаем внимательно один раз и потом просто будем компилировать и шить всё что хотим «лёгким движением руки».

Если мы прямо сейчас введём комманду «make», то получим скомпилированную прошивку для МК, который указан в параметрах DEVICE и CLOCK файла Makefile. Прошивка и вспомогательные файлы будут лежать в текущем каталоге. Процесс компиляции сопровождается комментариями компилятора и указаниями на ошибки (если таковые имеются).

Итак, программно мы уже готовы к проектам AVR. Осталось подыскать подходящий программатор (аппаратный разумеется). Какие же нам подойдут программаторы? Чтобы узнать вводим комманду:
avrdude -c ?

Теперь ты видишь просто огромный список поддерживаемых устройств-программаторов. Запоминаем/распечатываем и идём на радиобазар (опыт показал, что радиобазар — самый быстрый способ как приобрести, так и вернуть/обменять программатор))

Программатор.

Чтобы не мудрствовать лукаво, исходим из того, что он дожен быть наиболее стандартным. Главное: при покупке ОБЯЗАТЕЛЬНО оговаривай с продавцом безпроблемный возврат, если вдруг тебе что-то в нём не подойдёт. Не важно насколько программатор стандартный и должен правильно работать, если у тебя не получится его «завести», то какая разница по какой причине? Поэтому перед покупкой с продавцом договорился о возврате «если тебе по любой причине не подойдёт», он — кивнул головой, пришёл домой — подключил, проверил, работает — ОК. Если помучался, не смог заставить работать — вернулся на следующий день — забрал деньги. От того, как эти деньги вернул продавец, станет сразу понятно: иметь с ним долгосрочные отношения дальше или нет. Купил другой программатор и т.д.

Итак я приобрёл самый простой, первый попавшийся USB-программатор за $20-$25 который гордо нёс надпись, что он STK500v2 совместимый (кому интересно: and-tech.pl/programator-avrprog-usb-v2/ ). Но и это не важно, так как смотрим список поддерживаемых устройств утилитой avrdude и выбираем, что нашей душе угодно.

Так же установил значения FUSES, однако реально FUSES на МК менял отдельным скриптом — так спокойнее было :)

Разумеется, что строчки с коммандой exit стоят для того, чтобы не было случайного запуска скрипта и требовалось особой осознанности того, кто желает поменять фьюзы на МК.

Теперь мы и аппаратно подкованы. Можем создавать свой проект в новом каталоге, копируем туда наш Makefile, делаем необходимые изменения в Makefile (МК, частота, порт программатора, фьюзы-если необходимы), а далее всё просто. В Main.c пишем свою программу для МК. В «Терминале» в нашем каталоге вводим комманду «make» — наблюдаем процесс компиляции и возможные ошибки/предупреждения. Если всё ок, вводим «make flash» -наблюдаем процесс прошивки МК. Если в Makefile установили правильно и осознанно параметр FUSES, то можно запустить «make fuses» и программатор установит фьюзы на твоём МК.

Достаточное ПО.

Небольшой Видео-пример по теме статьи в котором мы редактируем, компилируем, прошиваем, настраиваем терминал и общаемся с МК:

Описанные в статье условия оказались для меня достаточными для удобного и простого создания AVR проектов на Mac OS X! Причём нативно и без каких-либо эммуляций. В следующей части, на примере одного из моих проектов, я покажу как это всё работает «в живую». Как программатор шьёт и питает схему, как через подключенный USB-RS232 шнурок мы тут же «общаемся» с МК, изменяя параметры работы схемы или снимая статистику.

Читайте также: