Nie można skompilować programu C na komputerze Mac po aktualizacji do Catalina 10.15

64

Jest poprzednie pytanie Nie można skompilować programu C na Macu po aktualizacji do Mojave , a odpowiedzi na to pytanie obejmowały większość wariantów tego, co poszło nie tak.

Teraz - od poniedziałku 2019-10-07 - możesz uaktualnić system do macOS Catalina 10.15. Ponownie, podczas aktualizacji, /usr/includekatalog został zdmuchnięty przez aktualizację, mimo że XCode 11.0 został zainstalowany przed aktualizacją (z Mojave 10.14.6) do Catalina. W związku z tym kompilatory zbudowane tak, aby oczekiwać, że istnieje /usr/includekatalog, już nie działają.

Główny zalecany krok w przypadku problemów z Mojave - użycie polecenia:

open /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg

nie działa poza bramą, ponieważ katalog /Library/Developer/CommandLineTools/Packages/nie istnieje (więc nie ma jeszcze .pkgpliku do otwarcia).

Czy istnieje dobry (oficjalny) sposób na utworzenie i wypełnienie katalogu /usr/include?

c xcode macos gcc macos-catalina Jonathan Leffler
źródło
Nie musisz /usr/includeużywać narzędzi programistycznych Apple z bieżącym kodem Xcode firmy Apple. Nagłówki i takie są w Xcode.app/Contents/Developer/Platforms/SomePlatform/SDKs/SomeSDK. (Przechowywanie nagłówków w różnych katalogach jest konieczne do obsługi wielu platform docelowych i dobrze jest nie /usr/includedopilnować, aby żadne kompilacje nie wykorzystały przypadkowo plików z niego podczas celowania w wersję inną niż system hosta.) Co xcode-select -pwskazuje ścieżka do aktywny katalog programistów?
Eric Postpischil,
Zbudowałem GCC 9.2.0 (na Mojave) i spodziewa się, że będzie mógł używać /usr/includenagłówków systemowych. Chciałbym móc nadal z tego korzystać, ale podejrzewam, że Apple w końcu porzuciło ostatnie ślady zgodności ze starszymi systemami Unix (do pewnego stopnia napis był na ścianie z systemem wymaganym do działania Mojave) ”). W takim przypadku prawdopodobnie będę musiał przebudować GCC, podając w jakiś sposób bieżącą lokalizację nagłówków systemowych - ręczne bashowanie, jak skonfigurować GCC.
Jonathan Leffler
1
@JonathanLeffler: Po aktualizacji do Cataliny mam również problem z brakiem niektórych plików (np. Stdlib.h), które są używane przez pakiet oprogramowania R podczas instalowania pakietów R. Próbowałem tego samego co ty dla macOS_10.14, ale nie jest to już możliwe. GCC, c ++ lub cokolwiek jest zainstalowane w / Library / Developer / CommandLineTools / usr / bin, ale R nie wie. Co mogę zrobić?
sebastiann
Od czasu aktualizacji do Cataliny jakiś tydzień temu stałem się ofiarą znanego obecnie problemu „podwójnego pisania” na nowych klawiaturach Maca, zmieniłem na zsh, zmieniłem zdanie i postanowiłem wrócić do bash i uaktualnij do wersji bash 5.0, teraz jestem tutaj, ponieważ nie mogę skompilować wersji bash 5.0. Zastanawiam się, czy poprawną odpowiedzią na ten problem nie jest po prostu zmniejszenie strat i przejście na Arch?
DryLabRebel
Jednym ze sposobów rozwiązania tego problemu jest użycie kompilatorów Xcode - jeśli są zainstalowane, wiedzą, gdzie znaleźć nagłówki systemowe. Wydaje się, że technika CPATH w przyjętej odpowiedzi działa dobrze. Jeszcze nie cierpiałem na komputerze Mac z powodu „podwójnego pisania” (o czym wiem). Mój iPhone zdecydował, że wpisałem wiele interesujących rzeczy, ale jak dotąd dotykać drewna, mój MacBook Pro był OK.
Jonathan Leffler

Odpowiedzi:

30

Dla mnie dodanie następującej ścieżki CPATHrozwiązania problemu:

export CPATH=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
Hamid
źródło
Próbowałem dodać CPATH; jednak nadal pojawia się ten sam błąd. po prostu próbuję zrobić proste cout << „cześć”;
Jon Pellant,
1
Kiedy spróbowałem, zadziałało to w zwykłym teście z GCC 9.2.0 zbudowanym pod Mojave przy użyciu obecnego Xcode 11.1 - dziękuję.
Jonathan Leffler,
To zadziałało dla mnie z GCC 9.2.0_1
Sandeep
5
Jeśli używasz narzędzi wiersza poleceń zamiast Xcode.app, użyjexport CPATH=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/
nalzok
Jeden kuriozum - Mam trochę kodu, który rozpoczął#include <stdlib.h>i wtedy nie udało się skompilować 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);narzeka:- Jeszcze, kiedy dodać#include <ctype.h>przed#include <stdlib.h>, kompiluje OK. Wciąż pracuję nad tym, co to znaczy i jak sobie z tym poradzić automatycznie.
Jonathan Leffler
48

Zanim przejdziesz dalej, zainstaluj narzędzia wiersza polecenia xcode.

xcode-select --install

Właściwie możesz to zrobić! Właściwie wszystkie nagłówki C znajdują się tutaj w tym folderze:

/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/

Musimy tylko utworzyć dowiązanie symboliczne dla wszystkich plików nagłówków w tym folderze:

/usr/local/include/

To zadziałało dla mnie! następujący wiersz poleceń zajmie się wszystkimi problemami:

sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

Dostaniesz ostrzeżenie. Niektóre nagłówki już istnieją, na przykład:

ln: /usr/local/include//tcl.h: File exists
ln: /usr/local/include//tclDecls.h: File exists
ln: /usr/local/include//tclPlatDecls.h: File exists
ln: /usr/local/include//tclTomMath.h: File exists
ln: /usr/local/include//tclTomMathDecls.h: File exists
ln: /usr/local/include//tk.h: File exists
ln: /usr/local/include//tkDecls.h: File exists
ln: /usr/local/include//tkPlatDecls.h: File exists

całkowicie ok, aby zignorować. to wszystko.

Roy
źródło
1
Tak, przypuszczam, że jest to możliwe - dziękuję za sugestię. Tak naprawdę nie spełnia moich wymagań dotyczących „higieny systemu” (np. Tych zduplikowanych nagłówków), a /usr/local/hierarchia katalogów jest przeznaczona raczej dla oprogramowania lokalnego niż oprogramowania systemowego. IMO, nagłówki powinny być, /usr/includea Apple po prostu boli.
Jonathan Leffler,
1
Jest na to sposób, może działać, możesz spróbować. W trybie odzyskiwania wyłącz SIP, a następnie podłącz /tryb zapisu. Następnie wypełnij /usr/includefolder. Jest tak, ponieważ w wersji 10.15 system montuje się jako tryb tylko do odczytu. bez wyłączenia SIP nie będzie można zamontować woluminu systemowego.
Roy,
@KomolNathRoy: dzięki za podpowiedzi. To działało dla mnie bardzo dobrze. W końcu mogłem zainstalować wszystkie moje poszukiwane pakiety w oprogramowaniu statystycznym R, ponieważ żaden R nie znajduje wszystkiego, czego potrzebuje do instalacji.
sebastiann
7
To rozwiązanie zadziałało dla mnie na Catalinie 10.15
Matthew Barbara
2
Wyłączenie SIP jest dla mnie nie do przyjęcia, nawet jako środek tymczasowy.
Jonathan Leffler,
22

TL; DR

Wydaje się, że Apple uważa /usr/includeza coś, która przeszła drogę dodo - to wymarły - a może to jest jak Monty Pythona Parrot .

Używanie dostarczonego przez Apple GCC (tak naprawdę to Clang pod dowolną inną nazwą, jak pokazują informacje o wersji) lub Clang pozwala uniknąć problemów. Zarówno /usr/bin/gcci /usr/bin/clangznajdzie biblioteki systemowe cztery poziomy katalogów poniżej:

/Applications/Xcode.app/Contents/Developer/Platforms/…

Jeśli zbudujesz własny GCC lub inny kompilator, musisz (prawdopodobnie) skonfigurować go, aby znaleźć biblioteki systemowe w katalogu aplikacji Xcode.

Eksploracje

Natychmiast po aktualizacji uruchomiłem XCode 11.0. Chciał zainstalować dodatkowe komponenty, więc pozwoliłem na to. Nie przywróciło /usr/includeto jednak katalogu ani katalogu /Library.

Jedną z innych rad z poprzedniego pytania było uruchomienie:

xcode-select --install

Robiąc to, twierdził, że pobrał narzędzia wiersza poleceń, i zapewnił, że /usr/bin/gcci /usr/bin/clangetc są obecne. To przydatny krok (chociaż nie sprawdziłem definitywnie, czy były wcześniej obecne).

$ /usr/bin/gcc --version
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
$

Za pomocą /usr/bin/gccmożna teraz kompilować programy:

$ make CC=/usr/bin/gcc al
co  RCS/al.c,v al.c
RCS/al.c,v  -->  al.c
revision 1.7
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM   -o al al.c -L/Users/jleffler/lib/64  -ljl
$

Jednak /usr/includenadal brakuje. /LibraryTeraz jest katalog :

$ ls /Library/Developer
CommandLineTools  PrivateFrameworks
$ ls /Library/Developer/CommandLineTools
Library SDKs    usr
$ ls /Library/Developer/CommandLineTools/SDKs
MacOSX.sdk      MacOSX10.14.sdk MacOSX10.15.sdk
$ ls /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$

Ani katalog Systemani nie Libraryzawiera niczego bardzo obiecującego.

Gdy wszystko inne zawiedzie, przeczytaj instrukcję

Następny krok - znajdź i przeczytaj informacje o wersji:

Nie ma tam żadnych informacji na ten temat. Prawdopodobnie (AFAICS, po zaledwie godzinie lub dwóch wysiłkach) Apple już nie obsługuje /usr/include- choć nadal ma w pełni załadowany /usr/lib( /libchoć nie ).

Czas sprawdzić kolejną kompilację z -vdodaną opcją GCC (w używanym makefile ustawienie UFLAGSdodaje opcję do wiersza poleceń kompilatora C):

$ make UFLAGS=-v CC=/usr/bin/gcc ww
co  RCS/ww.c,v ww.c
RCS/ww.c,v  -->  ww.c
revision 4.9
done
/usr/bin/gcc -I/Users/jleffler/inc -g -O3 -std=c11 -pedantic -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith  -Wold-style-definition -Wcast-qual -Wstrict-prototypes -DHAVE_MEMMEM -DHAVE_STRNDUP -DHAVE_STRNLEN  -DHAVE_GETDELIM -v  -o ww ww.c -L/Users/jleffler/lib/64  -ljl
Apple clang version 11.0.0 (clang-1100.0.33.8)
Target: x86_64-apple-darwin19.0.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang" -cc1 -triple x86_64-apple-macosx10.15.0 -Wdeprecated-objc-isa-usage -Werror=deprecated-objc-isa-usage -emit-obj -disable-free -disable-llvm-verifier -discard-value-names -main-file-name ww.c -mrelocation-model pic -pic-level 2 -mthread-model posix -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables -target-sdk-version=10.15 -target-cpu penryn -dwarf-column-info -debug-info-kind=standalone -dwarf-version=4 -debugger-tuning=lldb -ggnu-pubnames -target-linker-version 512.4 -v -resource-dir /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -I /Users/jleffler/inc -D HAVE_MEMMEM -D HAVE_STRNDUP -D HAVE_STRNLEN -D HAVE_GETDELIM -I/usr/local/include -O3 -Wall -Wextra -Werror -Wshadow -Wmissing-prototypes -Wpointer-arith -Wold-style-definition -Wcast-qual -Wstrict-prototypes -Wno-framework-include-private-from-public -Wno-atimport-in-framework-header -Wno-extra-semi-stmt -Wno-quoted-include-in-framework-header -pedantic -std=c11 -fdebug-compilation-dir /Users/jleffler/src/cmd -ferror-limit 19 -fmessage-length 110 -stack-protector 1 -fstack-check -mdarwin-stkchk-strong-link -fblocks -fencode-extended-block-signature -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.15.0 -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -vectorize-loops -vectorize-slp -o /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -x c ww.c
clang -cc1 version 11.0.0 (clang-1100.0.33.8) default target x86_64-apple-darwin19.0.0
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/local/include"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
 /Users/jleffler/inc
 /usr/local/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/include
 /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
 /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks (framework directory)
End of search list.
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld" -demangle -lto_library /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/libLTO.dylib -dynamic -arch x86_64 -macosx_version_min 10.15.0 -syslibroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk -o ww -L/Users/jleffler/lib/64 /var/folders/77/zx9nk6dn7_dg4xd4stvt42v00000gn/T/ww-4cb85b.o -ljl -L/usr/local/lib -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0/lib/darwin/libclang_rt.osx.a
 "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/dsymutil" -o ww.dSYM ww
$

Kluczowe informacje w tej zamieci danych to:

-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk

W rzeczywistości jest to katalog „główny” kompilacji, dlatego w podkatalogach for usri powinny znajdować się podkatalogi usr/include:

$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
Entitlements.plist SDKSettings.json   System
Library            SDKSettings.plist  usr
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr
bin     include lib     libexec share
$ ls /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/include
AppleTextureEncoder.h  dns_util.h             memory.h               simd
AssertMacros.h         dtrace.h               menu.h                 slapi-plugin.h
Availability.h         editline               miscfs                 spawn.h
AvailabilityInternal.h err.h                  module.modulemap       sqlite3.h
AvailabilityMacros.h   errno.h                monetary.h             sqlite3ext.h
AvailabilityVersions.h eti.h                  monitor.h              stab.h
…lots more lines…
dirent.h               mach-o                 security               xcselect.h
disktab.h              mach_debug             semaphore.h            xlocale
dispatch               machine                servers                xlocale.h
dlfcn.h                malloc                 setjmp.h               xpc
dns.h                  math.h                 sgtty.h                zconf.h
dns_sd.h               membership.h           signal.h               zlib.h
$

To pokazuje, że długa na milę i całkowicie niepoznawalna nazwa katalogu zawiera standardowe nagłówki C i POSIX oraz dodatki specyficzne dla Apple.

Poprzedni /usr/local/katalog wydaje się nienaruszony; ostrzeżenie o usr/local/includenieistnieniu pod -isysrootdirjest nieszkodliwe (i niewidoczne bez -vopcji).

Jonathan Leffler
źródło
Niestety nie mogłem zastosować się do Twojej sugestii. Otrzymuję ten sam błąd w przypadku aktualizacji Catalina. Dzięki vscode nie mogłem budować aplikacji C ++ i wchar.hbłąd nie został znaleziony. Próbowałem dołączyć ten folder -I / Applications / Xcode.app / Contents / Developer / Platforms / MacOSX.platform / Developer / SDKs / MacOSX.sdk / usr / include i iam otrzymuję inne błędy, takie jak brakujące symbole dla „error: no member nazwany „isless” w globalnej przestrzeni nazw ”
user3279954,
Włączone --verbosew pliku zadań i zauważyłem, że vs vs code szuka /usr/include/c++/v1/folderu, który już nie istnieje w Catalina. Dodano również następujący folder wraz z powyższym sdk include i teraz działa. „-I / Library / Developer / CommandLineTools / usr / include / c ++ / v1 /”,
user3279954,
@trojanfoe — I prefer SCCS but in 1999 it wasn’t clear whether SCCS was going to work sanely post-Y2K (and there wasn’t a good open source implementation of SCCS that I knew of), so I reluctantly switched to RCS.
Jonathan Leffler
Wow: D W każdym razie, jaki jest problem z /usr/includezaginięciem? Zawsze była domyślnie częścią ścieżki dołączającej kompilatora, więc użytkownik nigdy nie musiał o tym wiedzieć (poza tym, kiedy próbujesz znaleźć miejsce, gdzie coś zostało zadeklarowane). Clang robi to samo ze swoją ścieżką SDK pod, Xcode.appwięc efekt netto jest taki sam.
trojanfoe,
1
@trojanfoe: jednym problemem (moim głównym problemem) z nieistniejącym /usr/includeAWOL jest to, że jeśli zbudowałeś swój własny GCC ze źródła, prawdopodobnie został on skompilowany w celu znalezienia nagłówków systemowych /usr/includei dlatego kompilacje nie powiodły się. Chcę używać najnowszego GCC, a także Clanga. Cieszę się, że używam Apple Clang, ale nie jestem szczęśliwy, że Apple Clang udaje GCC - to nie to samo co GCC. Nie opracowałem jeszcze przepisu na budowę GCC z przeniesionymi nagłówkami systemu. (Myślę, że --with-native-system-header-dir="${XCODE_HDR}"jest to część odpowiedzi; nie jest to jednak cała odpowiedź.)
Jonathan Leffler,
7

Ustaw następujące Makezmienne niejawne , aby wskazywały, gdzie znajdują się teraz nagłówki dla narzędzi wiersza polecenia Xcode (CLI Xcode):

export CFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS+=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk

-isysrootOpcja aktualizuje położenie plików korzeniowych z dala od katalogu głównego systemu /.

To gwarantuje, że wspólne /usr/*pliki zostaną znalezione w ich nowym miejscu.

Oznacza to, że pliki w /Library/Developer/CommandLineTools/SDKs/MacOSX.sdksą teraz znalezione. Te pliki to:

Entitlements.plist 
Library
SDKSettings.json
SDKSettings.plist
System
usr
bez płaszcza
źródło
W moich plikach makefile (i większości innych plików makefile, które widzę) CFLAGSjest znacznie bardziej złożony niż jedna pojedyncza opcja - -isysrootopcja musiałaby być „oprócz” innych ustawień (wiele innych ustawień). Może istnieć jądro pomysłu (przekaż -isysrootopcję i położenie poniżej /Library/Developer/…), ale wymagałoby to dopracowania, zanim będzie gotowe na pierwszą porę.
Jonathan Leffler
@JonathanLeffler Używanie export CFLAGS+=-isysroot ...zamiast tego będzie działać dla tego przypadku użycia. Jest to jedyne rozwiązanie, które działało dla mnie (w Mojave (10.14) z pakietem Catalina (10.15) SDK. Nie mam .pkgpliku, o którym wszyscy mówią, mimo że mój XCode i narzędzia wiersza poleceń są aktualne).
Norswap
@Norswap - istnieje ogromna różnica między użyciem CFLAGS=…i CFLAGS+=….
Jonathan Leffler,
@JathanathanLeffler zgodził się. Zaktualizowałem odpowiedź do użycia +=. Dzięki @Norswap.
płaszczu
1
Alternatywnie, doszedłem do wniosku, że ustawienie SDKROOTtej samej wartości sdk ( /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk) również będzie dla mnie działać!
Norswap,
4

Jestem nowicjuszem w kompilatorze C ++ dla R w OSX i mam ten sam problem, że C ++ nie mógł znaleźć nagłówka po aktualizacji OS ( brak pliku matematycznego.h, mimo że tam był ). Postępowałem zgodnie z instrukcjami z https://thecoatlessprofessor.com/programming/cpp/r-compiler-tools-for-rcpp-on-macos/, ale nic się nie zmieniło.

Wreszcie zadziałało to po ponownej instalacji interfejsu CLI Xcode

xcode-select --install

a następnie zmień flagi na Var zgodnie z sugestią @Coatless:

export CFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CCFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CXXFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
export CPPFLAGS=-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
Nancy
źródło
1

W moim przypadku zdawało się, że mam llvmi gcczainstalowałem również za pomocą Homebrew. Kiedy je usunąłem i w ten sposób w pełni polegałem na macOS, mogłem znaleźć nagłówki i kompilacja znów działała.

frbl
źródło
0

Zależność apue.h nadal była brakująca /usr/local/includepo mojej odpowiedzi Komol Nath Roy na to pytanie.

Pobrałem zależność ręcznie z git i umieściłem w niej /usr/local/include

Matthew Barbara
źródło
Nagłówek apue.hpochodzi od W Richarda Stevensa, Stephen A Rago Advanced Programming in Unix Environment, 3. Edn 2013. AFAIK, nigdy nie został dostarczony przez Apple jako nagłówek systemowy. (Nie ma go /usr/includena moim komputerze, na którym nadal działa Mojave). Jeśli raz go zainstalowano /usr/include, prawdopodobnie został utworzony ręcznie, a nie dostarczany przez Apple. Jako taki powinien był zostać wcześniej zainstalowany /usr/local/include.
Jonathan Leffler
Przepraszam, moje naiwne pytanie, ale właśnie dostałem C ++ w tym tygodniu. Czy zależności / nagłówki są zarządzane ręcznie w c ++? jeśli tak, czy powinienem umieścić wszystkie wymienione zależności / nagłówki /usr/include?
Matthew Barbara
1
P1: Mniej więcej. Zależy to nieco od tego, co masz na myśli, ale musisz martwić się o zależności i nagłówki dla C lub C ++, jeśli nagłówki nie są standardowe na komputerach, z którymi pracujesz. Potem pojawia się pytanie - jaki jest standard? A najlepszą odpowiedzią na to pytanie jest „to zależy” i zależy od wielu czynników - w tym od „platformy” (O / S, kompilator). Pytanie 2 brzmi „Nie, zwykle nie powinieneś niczego umieszczać /usr/include” - /usr/local/includezamiast tego użyj . Ogólnie rzecz biorąc, jest to najbezpieczniejsza opuścić /usr/includei /usr/libsam, i dodać materiału pod /usr/localzamiast.
Jonathan Leffler
0

Rozwiązanie było prostsze niż myślałem. Zainstaluj clang / llvm.

brew install llvm

Następnie musimy sami stworzyć dowiązania symboliczne.

for f in /usr/local/Cellar/llvm/9.0.0_1/bin/clang*; do ln -s ${f} /usr/local/bin/"${f##*/}"; done

I

ln -s /usr/local/Cellar/llvm/9.0.0_1/include/c++ /usr/local/include/c++

W zależności od wersji llvm zmodyfikuj powyższe polecenia.

Teraz możesz kompilować programy C ++ bez przekazywania żadnych niestandardowych flag.

clang++ hello.cpp
Salil
źródło
0

Dla mnie działa to następująco:

1. xcode-select --install

2. sudo ln -s /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/* /usr/local/include/

3. export SDKROOT=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
pfcstyle
źródło