[cfe-dev] clang built from source in Mac OSX 10.14 with apple-clang/Xcode missing stdlib from include search path

Thu Sep 26 04:36:20 PDT 2019

Yeah it'd be great for it to work out of the box, the headers are
already there in the normal install of Xcode, so not like it's "missing"
some other component and it would be great to work out of the box. Based
on the (non-)responses I guess I won't know how receptive the project
will be until I submit a patch.

On 9/25/19 8:49 PM, Hans Wennborg wrote:
> I'm always confused when trying to get locally-built Clang to find
> stdlib headers on my Mac.
>
> Last time, after upgrading to Mojave, following the TL;DR advice from
> this answer made it work for me: https://stackoverflow.com/a/52530212
>
> It would certainly be nice if this could somehow work out of the box.
>
> On Wed, Sep 25, 2019 at 7:17 AM Jens Jorgensen via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
>> I recently cloned llvm from git and did a build of clang on my Macbook
>> (OSX 10.14.6). I have Xcode (11.0) installed and built using Xcode's
>> included apple-clang. The build worked fine but when I went to compile
>> my project I got an error where it was trying to #include a stdlib
>> header file. I'm not really sure but I think this is because in MacOS
>> Mojave by default the os has System Integrity Protection enabled which
>> among other things prevents modification to at least some locations
>> under /usr (root user unable to ln -s ... /usr/include/c++, tried that).
>> So Xcode does not install or symlink the standard library headers into
>> /usr/include. apple-clang as installed already includes the installed
>> stdlib header directories in its search path. Looking at the current git
>> source I don't see a way to build clang to set a directory to look in
>> for the stdlib. I did try -DGCC_INSTALL_PREFIX=... and that did not do
>> the trick, apparently because it does not end up keeping that path for
>> searching include <...>.
>>
>> I made a local git branch and made some changes to allow me to build a
>> clang++ that includes the installed location in the include search path
>> but before I log a bug/submit a change for review I wanted to see what
>> constraints around this would end up being acceptable. Should the cmake
>> scripts automatically pick this up by default on OSX if building with
>> the Xcode-supplied compiler? Should it be structured/would it be useful
>> to introduce a top-level #define to set this default stdlib search path
>> in clang/include/clang/Config/config.h.cmake?
>>
>> For reference, here's a comparison on a test.cpp file containing simple
>> #include <string>:
>>
>> ~/src/clang-build-20190828/bin/clang++  -v -c /tmp/test.cpp
>> clang version 10.0.0 (https://github.com/llvm/llvm-project.git
>> 92ed86d239cdd6ed97dae3084f6537088da88677)
>> Target: x86_64-apple-darwin18.7.0
>> Thread model: posix
>> InstalledDir: /Users/user/src/clang-build-20190828/bin
>>  "/Users/user/src/clang-build-20190828/bin/clang-10" -cc1 -triple
>> x86_64-apple-macosx10.14.0 -Wdeprecated-objc-isa-usage
>> -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
>> -disable-llvm-verifier -discard-value-names -main-file-name test.cpp
>> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> -mframe-pointer=all -masm-verbose -munwind-tables -target-cpu penryn
>> -dwarf-column-info -debugger-tuning=lldb -ggnu-pubnames
>> -target-linker-version 450.3 -v -coverage-notes-file
>> /Users/user/src/llvm-project/test.gcno -resource-dir
>> /Users/user/src/clang-build-20190828/lib/clang/10.0.0 -stdlib=libc++
>> -internal-isystem
>> /Users/user/src/clang-build-20190828/bin/../include/c++/v1
>> -internal-isystem /usr/include/c++/v1 -internal-isystem
>> /usr/local/include -internal-isystem
>> /Users/user/src/clang-build-20190828/lib/clang/10.0.0/include
>> -internal-externc-isystem /usr/include -fdeprecated-macro
>> -fdebug-compilation-dir /Users/user/src/llvm-project -ferror-limit 19
>> -fmessage-length 80 -stack-protector 1 -fblocks
>> -fencode-extended-block-signature -fregister-global-dtors-with-atexit
>> -fobjc-runtime=macosx-10.14.0 -fcxx-exceptions -fexceptions
>> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o
>> test.o -x c++ /tmp/test.cpp
>> clang -cc1 version 10.0.0 based upon LLVM 10.0.0svn default target
>> x86_64-apple-darwin18.7.0
>> ignoring nonexistent directory
>> "/Users/user/src/clang-build-20190828/bin/../include/c++/v1"
>> ignoring nonexistent directory "/usr/include/c++/v1"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /usr/local/include
>>  /Users/user/src/clang-build-20190828/lib/clang/10.0.0/include
>>  /usr/include
>>  /System/Library/Frameworks (framework directory)
>>  /Library/Frameworks (framework directory)
>> End of search list.
>> /tmp/test.cpp:1:10: fatal error: 'string' file not found
>> #include <string>
>>          ^~~~~~~~
>> 1 error generated.
>>
>>  and with the Xcode clang:
>>
>> clang++  -v -c /tmp/test.cpp
>> Apple clang version 11.0.0 (clang-1100.0.33.8)
>> Target: x86_64-apple-darwin18.7.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.14.0 -Wdeprecated-objc-isa-usage
>> -Werror=deprecated-objc-isa-usage -emit-obj -mrelax-all -disable-free
>> -disable-llvm-verifier -discard-value-names -main-file-name test.cpp
>> -mrelocation-model pic -pic-level 2 -mthread-model posix
>> -mdisable-fp-elim -fno-strict-return -masm-verbose -munwind-tables
>> -target-cpu penryn -dwarf-column-info -debugger-tuning=lldb
>> -ggnu-pubnames -target-linker-version 512.4 -v -coverage-notes-file
>> /Users/jbj1/src/llvm-project/test.gcno -resource-dir
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/11.0.0
>> -stdlib=libc++ -internal-isystem
>> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
>> -Wno-framework-include-private-from-public
>> -Wno-atimport-in-framework-header -Wno-extra-semi-stmt
>> -Wno-quoted-include-in-framework-header -fdeprecated-macro
>> -fdebug-compilation-dir /Users/jbj1/src/llvm-project -ferror-limit 19
>> -fmessage-length 80 -stack-protector 1 -mdarwin-stkchk-strong-link
>> -fblocks -fencode-extended-block-signature
>> -fregister-global-dtors-with-atexit -fobjc-runtime=macosx-10.14.0
>> -fcxx-exceptions -fexceptions -fmax-type-align=16
>> -fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++ /tmp/test.cpp
>> clang -cc1 version 11.0.0 (clang-1100.0.33.8) default target
>> x86_64-apple-darwin18.7.0
>> ignoring nonexistent directory "/usr/include/c++/v1"
>> #include "..." search starts here:
>> #include <...> search starts here:
>>  /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1
>>  /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
>>  /usr/include
>>  /System/Library/Frameworks (framework directory)
>>  /Library/Frameworks (framework directory)
>> End of search list.
>>
>>
>> --
>> Jens B. Jorgensen
>> jbj1 at ultraemail.net
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

-- 
Jens B. Jorgensen
jbj1 at ultraemail.net