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

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Renato Golin via cfe-dev
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
[hidden email]


_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang built from source in Mac OSX 10.14 with apple-clang/Xcode missing stdlib from include search path

Renato Golin via cfe-dev
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
<[hidden email]> 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
> [hidden email]
>
>
> _______________________________________________
> cfe-dev mailing list
> [hidden email]
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang built from source in Mac OSX 10.14 with apple-clang/Xcode missing stdlib from include search path

Renato Golin via cfe-dev
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
> <[hidden email]> 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
>> [hidden email]
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> [hidden email]
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

--
Jens B. Jorgensen
[hidden email]

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang built from source in Mac OSX 10.14 with apple-clang/Xcode missing stdlib from include search path

Renato Golin via cfe-dev
In reply to this post by Renato Golin via cfe-dev
On 2019-09-25 14:49, Hans Wennborg via cfe-dev 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.

When building Clang the build system could run "xcrun --show-sdk-path"
to identify the SDK path. Or to be even more flexible: when running
Clang it could run the above code and it will avoid the need for hard
coding the path to the SDK.

--
/Jacob Carlborg

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: clang built from source in Mac OSX 10.14 with apple-clang/Xcode missing stdlib from include search path

Renato Golin via cfe-dev
On 9/30/19 4:28 AM, Jacob Carlborg via cfe-dev wrote:

> On 2019-09-25 14:49, Hans Wennborg via cfe-dev 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.
>
> When building Clang the build system could run "xcrun --show-sdk-path"
> to identify the SDK path. Or to be even more flexible: when running
> Clang it could run the above code and it will avoid the need for hard
> coding the path to the SDK.
>
Yeah, there are lots of ways it /could/ be solved but I guess what I'm
proposing is that if there exists a default SDK that goes with the
compiler you're using to build clang and we know about it, shouldn't we
be providing the mechanism internally to find it (only in the case where
it cannot be found in the obvious places eg. /usr/include)? In the
ordinary case (where it is installed in /usr/include) the compiler would
already pick it up, so it's not like we're injecting strange behavior
right? Or I'm crazy? I don't know, but ending up with a good compiler
that cannot find the std lib, even though the previous compiler did, is
just kicking the problem "upstream". It seems a reasonable minimal
requirement that running clang++ without extra include paths should be
able to find the standard library.

--
Jens B. Jorgensen
[hidden email]

_______________________________________________
cfe-dev mailing list
[hidden email]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev