Есть предыдущий вопрос: « Не могу скомпилировать программу C на Mac после обновления до Mojave» , и ответы на него охватили большинство вариантов того, что идет не так.
Теперь, по состоянию на понедельник 2019-10-07, вы можете перейти на macOS Catalina 10.15. Еще раз, во время обновления /usr/include
каталог был снесен обновлением, даже несмотря на то, что XCode 11.0 был установлен до обновления (с Mojave 10.14.6) до Catalina. Следовательно, компиляторы, рассчитанные на то, что /usr/include
каталог существует, больше не работают.
Основной рекомендуемый шаг для проблем Мохаве - использование команды:
open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg
не работает вне шлюза, потому что каталог /Library/Developer/CommandLineTools/Packages/
не существует (поэтому еще нет .pkg
файла для открытия).
Есть ли хороший (официальный) способ создания и заполнения каталога /usr/include
?
/usr/include
использовать инструменты разработчика Apple с текущим Xcode Apple. Заголовки и тому подобноеXcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK
. (Хранение заголовков в разных каталогах необходимо для поддержки нескольких целевых платформ, и хорошо не иметь/usr/include
гарантии, что никакие компиляции не будут случайно использовать файлы из него при нацеливании на версию, отличную от хост-системы.) Чтоxcode-select -p
показывает путь к активный каталог разработчиков?/usr/include
для системных заголовков. Я хотел бы иметь возможность использовать это все еще, хотя я подозреваю, что Apple, наконец, выбросила последние остатки совместимости с унаследованными системами Unix (в некоторой степени, запись была на стене с системой, необходимой для работы Мохаве) «). В этом случае мне, вероятно, придется пересобрать GCC, указав текущее местоположение системных заголовков, - ручная фиксация того, как настроить GCC.Ответы:
Для меня добавление следующего пути для
CPATH
решения проблемы:источник
export CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
#include <stdlib.h>
а потом не смог скомпилировать, жалуясь на:In file included from …/usr/include/sys/wait.h:110, —— from …/usr/include/stdlib.h:66, —— from bm.c:27: —— …/usr/include/sys/resource.h:443:9: error: no previous prototype for ‘getiopolicy_np’ [-Werror=missing-prototypes] —— 443 | int getiopolicy_np(int, int) __OSX_AVAILABLE_STARTING(__MAC_10_5, __IPHONE_2_0);
- Тем не менее, когда я добавляю#include <ctype.h>
раньше#include <stdlib.h>
, он компилируется нормально. До сих пор выясняю, что это значит и как с этим справиться автоматически.Прежде чем продолжить, обязательно установите инструменты командной строки xcode.
На самом деле, вы можете сделать это! На самом деле все заголовки C находятся здесь в этой папке:
Нам просто нужно создать символическую ссылку для всех файлов заголовков в эту папку:
Это сработало для меня! Следующая командная строка позаботится обо всех проблемах:
Вы получите предупреждение. Некоторые из заголовков уже существуют, например:
совершенно нормально игнорировать это все.
источник
/usr/local/
иерархия каталогов предназначена для локального программного обеспечения, а не для системного программного обеспечения. ИМО, заголовки должны быть,/usr/include
а Apple - просто боль./
в режиме записи. Затем заполните/usr/include
папку. Это потому, что в 10.15 система монтируется как режим только для чтения. без отключения SIP вы не сможете смонтировать системный том.TL; DR
Похоже, что Apple считает
/usr/include
что-то, что пошло по пути додо - оно вымерло - или, возможно, это как Попугай Монти Пайтона .Использование предоставленного Apple GCC (на самом деле это Clang под любым другим именем, как показывает информация о версии) или Clang позволяет избежать проблем. Оба
/usr/bin/gcc
и/usr/bin/clang
найдут системные библиотеки четырьмя уровнями каталогов ниже:Если вы создаете свой собственный GCC или другой компилятор, вам (вероятно) потребуется настроить его, чтобы найти системные библиотеки в каталоге приложения Xcode.
Исследования
Сразу после обновления я запустил XCode 11.0. Он хотел установить некоторые дополнительные компоненты, поэтому я позволил это сделать. Однако, это не восстановило
/usr/include
или каталог под/Library
.Одним из других советов в предыдущем вопросе было выполнить:
При этом он утверждал, что загрузил утилиты командной строки, и гарантировал, что
/usr/bin/gcc
и/usr/bin/clang
т. Д. Присутствовали. Это полезный шаг (хотя я точно не проверял, присутствовали ли они раньше).Используя
/usr/bin/gcc
, теперь можно составлять программы:Тем не менее,
/usr/include
по-прежнему отсутствует. В настоящее время существует каталог/Library
:Ни каталог,
System
ниLibrary
каталог не содержат ничего очень многообещающего.Когда ничего не помогает, прочитайте инструкцию
Следующий шаг - найдите и прочитайте примечания к выпуску:
Там нет информации, которая имеет отношение к этому. Таким образом, вероятность (AFAICS, после всего лишь часа или двух усилий) Apple больше не поддерживает
/usr/include
- хотя она все еще полностью загружена/usr/lib
(/lib
хотя нет ).Пришло время проверить другую компиляцию с
-v
добавленной опцией GCC (в используемом мной make-файле настройкаUFLAGS
добавляет опцию в командную строку компилятора C):Ключевая информация в этой вьюге данных:
Это по сути корневой каталог для компиляции, поэтому в нем должны быть подкаталоги для
usr
иusr/include
:Это показывает, что имя каталога длиной в милю и полностью не запоминающееся содержит стандартные заголовки C и POSIX, а также специфичные для Apple дополнения.
Предыдущий
/usr/local/
каталог кажется неповрежденным; предупреждение о том, чтоusr/local/include
не существует под-isysrootdir
безвредным (и не виден без-v
опции).источник
wchar.h
ошибку not found. Я попытался включить эту папку -I / Applications / Xcode.app / Contents / Developer / Platforms / MacOSX.platform / Developer / SDKs / MacOSX.sdk / usr / include и получить другие ошибки, например о пропущенных символах для «error: no member» с именем 'isless' в глобальном пространстве имен "--verbose
в файле задач и заметил, что vs code просматривает/usr/include/c++/v1/
папку, которой больше нет в catalina. Также добавили следующую папку вместе с вышеупомянутым sdk include и теперь она работает. "-I / Библиотека / Разработчик / CommandLineTools / usr / include / c ++ / v1 /",/usr/include
пропажи? Это всегда было неявно частью пути включения компилятора, поэтому пользователю никогда не нужно было знать об этом (кроме случаев, когда вы пытались найти, где что-то было объявлено). Clang делает то же самое со своим путем SDK подXcode.app
так что чистый эффект тот же./usr/include
AWOL заключается в том, что если вы создали свой собственный GCC из исходного кода, он, вероятно, был скомпилирован для поиска системных заголовков,/usr/include
и поэтому компиляция не удалась. Я хочу использовать последнюю версию GCC, а также Clang. Я счастлив использовать Apple Clang, но я не рад использовать Apple Clang, маскирующуюся под GCC - это не то же самое, что GCC. Я еще не разработал рецепт для создания GCC с перемещением системных заголовков. (Я думаю, что--with-native-system-header-dir="${XCODE_HDR}"
это часть ответа; однако это не весь ответ.)Задайте следующие неявные
Make
переменные, чтобы они указывали, где теперь расположены заголовки для инструментов командной строки Xcode (CLI Xcode):-isysroot
Опция обновляет местоположение корневых файлов вдали от системной директории корня/
.Таким образом, это гарантирует, что общие
/usr/*
файлы будут найдены на новом месте.То есть файлы
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
теперь найдены. Эти файлы:источник
CFLAGS
это намного сложнее, чем один единственный параметр --isysroot
параметр должен быть «в дополнение к» другим настройкам (множество других настроек). Здесь может быть ядро идеи (передайте-isysroot
опцию и расположение под ней/Library/Developer/…
), но для ее подготовки к прайм-тайму потребуется некоторая полировка.export CFLAGS+=-isysroot ...
вместо этого будет работать для этого варианта использования. Это единственное решение, которое работало для меня (в Mojave (10.14) с Catalina (10.15) SDK. У меня нет.pkg
файла, о котором все говорят, хотя мой XCode и инструменты командной строки обновлены).CFLAGS=…
иCFLAGS+=…
.+=
. Спасибо @Norswap.SDKROOT
того же значения sdk (/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
) будет работать для меня!Я новичок с компилятором C ++ для R в OSX, и у меня возникла та же проблема, что C ++ не мог найти заголовок после обновления ОС ( отсутствует math.h, хотя он там был ). Я следовал инструкциям с https://thecoatlessprofess.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/, но ничего не изменилось.
Наконец, это сработало для меня после того, как я переустановил CLI Xcode
а затем измените флаги на Var, как предложено @Coatless:
источник
В моем случае я, кажется,
llvm
иgcc
установил с помощью доморощенного. Когда я удалил их и, таким образом, полностью полагался на лязг MacOS, он мог найти заголовки, и компиляция снова заработала.источник
apue.h зависимость все еще отсутствовала в моем
/usr/local/include
после подписки ответил на вопрос Комола Нат Роя в этом вопросе.Я скачал зависимость вручную из git и поместил ее в
/usr/local/include
источник
apue.h
принадлежит У Ричарду Стивенсу (W Richard Stevens), Расширенное программирование Стивена А Раго в среде Unix, 3-е издание 2013 г. AFAIK, он никогда не был предоставлен Apple в качестве системного заголовка. (На/usr/include
моем компьютере не работает Mojave.) Если он когда-то был установлен/usr/include
, скорее всего, он был создан вручную, а не предоставлен Apple. Как таковой, он должен был быть установлен/usr/local/include
ранее./usr/include
?/usr/include
» - используйте/usr/local/include
вместо этого. Как правило, это безопаснее оставить/usr/include
и в/usr/lib
одиночку, и добавить материал под/usr/local
вместо этого.Решение было проще, чем я думал. Установите clang / llvm.
Тогда нам нужно самим создать символические ссылки.
А также
В зависимости от вашей версии llvm измените приведенные выше команды.
Теперь вы можете компилировать программы на C ++, не передавая никаких пользовательских флагов.
источник
Я попробовал 1) вручную связать 2) заварить установить llvm, но они не работали.
Наконец, это сработало для меня: https://gitmemory.com/issue/pytorch/pytorch/31190/565153503
Установив следующие env vars:
источник
Для меня это хорошо работает следующим образом:
источник