Libtool search path on MacOS

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Libtool search path on MacOS

Xin Wang via cfe-dev
This is a continuation of http://lists.llvm.org/pipermail/cfe-dev/2017-June/054411.html, which I could not reply to because I wasn't actually subscribed to the list. My apologies.

>> But when I build it on MacOS, it doesn't find any gcc installation (though I do
>> have it installed with homebrew). Since I'm building out-of-tree, the
>> "../lib/clang/x.y.z/include" path is invalid. So the tool cannot locate
>>C/C++ header files. My current workaround is to use the C_INCLUDE_PATH
>> and CPLUS_INCLUDE_PATH environment variables to point to my C/C++
>> installations. Is there a better way of doing this on Mac?

>I don't think that homebrew installs anything in any of the default
>paths. I would recommend installing Xcode and the command line tools. Or
>alternatively only the command line tools.

I had already installed Xcode and the command line tools, but I don't see how this would help.

Scott

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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
On 2017-06-26 20:27, scott constable via cfe-dev wrote:

> I had already installed Xcode and the command line tools, but I don't
> see how this would help.

Well, if you don't have Xcode and the command line tools installed there
wouldn't be a GCC/Clang installation to find (I don't think it would be
able to find the one in homebrew). But if you already have that
installed, then unfortunately, I don't know.

Although I'm not sure if you're talking about the C/C++ standard library
headers or the internal compiler headers. The former should be found in
the standard include paths, /usr/include. The latter are only search for
in the relative include path, ../lib/clang/x.y.z/include, in my experience.

In my tool [1] I solved that by embedding the internal headers in the
executable [2][3].

[1] https://github.com/jacob-carlborg/dstep

[2]
https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L37-L38

[3]
https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L52-L54

--
/Jacob Carlborg

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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
Sorry, I should have clarified. The C/C++ headers are the ones which cannot be found. For clarity, here's the output of my tool with the -v flag (I've hidden some sensitive names with ***):

clang version 4.0.0 (tags/RELEASE_400/final)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: 
clang Invocation:
 "clang-tool" "-cc1" "-triple" "x86_64-apple-macosx10.12.0" "-Wdeprecated-objc-isa-usage" "-Werror=deprecated-objc-isa-usage" "-fsyntax-only" "-disable-free" "-disable-llvm-verifier" "-discard-value-names" "-main-file-name" "AddressOfTest.cpp" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" "-munwind-tables" "-target-cpu" "penryn" "-target-linker-version" "278.4" "-v" "-dwarf-column-info" "-debugger-tuning=lldb" "-resource-dir" "***/build-debug/bin/../lib/clang/4.0.0" "-c-isystem" "/usr/local/include" "-stdlib=libc++" "-fdeprecated-macro" "-fdebug-compilation-dir" "***/build-debug" "-ferror-limit" "19" "-fmessage-length" "95" "-stack-protector" "1" "-fblocks" "-fobjc-runtime=macosx-10.12.0" "-fencode-extended-block-signature" "-fcxx-exceptions" "-fexceptions" "-fmax-type-align=16" "-fdiagnostics-show-option" "-fcolor-diagnostics" "-x" "c++" "test.cpp"
clang -cc1 version 4.0.0 based upon LLVM 4.0.0 default target x86_64-apple-darwin16.6.0
ignoring nonexistent directory "/***/build-debug/bin/../include/c++/v1"
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory "***/build-debug/bin/../lib/clang/4.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.

Both my Xcode clang and my homebrew-installed clang find the headers through the relative path "../include/c++/v1". This won't be possible with my libtool unless (a) I move my libtool into the directory where clang is installed, or (b) I also distribute the C/C++ headers with my libtool. Both of these solutions is ugly, so I would prefer something nicer.

Thanks,

Scott

On Mon, Jun 26, 2017 at 3:24 PM, Jacob Carlborg via cfe-dev <[hidden email]> wrote:
On 2017-06-26 20:27, scott constable via cfe-dev wrote:

I had already installed Xcode and the command line tools, but I don't
see how this would help.

Well, if you don't have Xcode and the command line tools installed there wouldn't be a GCC/Clang installation to find (I don't think it would be able to find the one in homebrew). But if you already have that installed, then unfortunately, I don't know.

Although I'm not sure if you're talking about the C/C++ standard library headers or the internal compiler headers. The former should be found in the standard include paths, /usr/include. The latter are only search for in the relative include path, ../lib/clang/x.y.z/include, in my experience.

In my tool [1] I solved that by embedding the internal headers in the executable [2][3].

[1] https://github.com/jacob-carlborg/dstep

[2] https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L37-L38

[3] https://github.com/jacob-carlborg/dstep/blob/master/clang/Compiler.d#L52-L54

--
/Jacob Carlborg

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


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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
On 2017-06-26 21:37, scott constable via cfe-dev wrote:

> Sorry, I should have clarified. The C/C++ headers are the ones which
> cannot be found. For clarity, here's the output of my tool with the -v
> flag (I've hidden some sensitive names with ***):
>
> clang version 4.0.0 (tags/RELEASE_400/final)
> ignoring nonexistent directory "/***/build-debug/bin/../include/c++/v1"
> ignoring nonexistent directory "/usr/include/c++/v1"
> ignoring nonexistent directory
> "***/build-debug/bin/../lib/clang/4.0.0/include"
> #include "..." search starts here:
> #include <...> search starts here:
>   /usr/local/include
>   /usr/include
>   /System/Library/Frameworks (framework directory)
>   /Library/Frameworks (framework directory)
> End of search list.
>
> Both my Xcode clang and my homebrew-installed clang find the headers
> through the relative path "../include/c++/v1". This won't be possible
> with my libtool unless (a) I move my libtool into the directory where
> clang is installed, or (b) I also distribute the C/C++ headers with my
> libtool. Both of these solutions is ugly, so I would prefer something nicer.

If only Xcode is installed the headers are available at:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include

This can be verified by running "clang -E  - -v < /dev/null". You'll see
the above two paths (or something similar depending on which version of
Xcode) are two of the paths Clang will search in.

If the command line tools are installed as well, the headers will be
available in "/usr/include" as well. As you can see with the above
command, "/usr/include" is one of the paths Clang will search in.

As can be seen in the output from your tool, the paths in
/Applications/Xcode.app are not searched in. Since it doesn't find the
headers I suspect you don't have the command line tools installed.

Note that even though you can invoke "clang" on the command line to
compile code, it doesn't necessarily mean that the command line tools
are installed. You can install the command line tools by running
"xcode-select --instal". If they're already installed, you'll get a message.

All this trouble with these paths are due to, I believe, Apple wants the
Xcode app bundle to be completely self contained and not install
anything outside of it unless the user explicitly asks for it. I'm
guessing this it to be compatible with the App Store.

--
/Jacob Carlborg

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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
Hmmm. I have the same issue as this gentleman: https://forums.developer.apple.com/thread/71209. I do have Xcode CLI tools installed, but it has installed an older version of libc++ in my /usr/include. The installed directory is /usr/include/c++/4.2.1 (I think this is either C++03 or C++98), but my libtool expects /usr/include/c++/v1. So is this actually an unresolved issue with Xcode?

Scott

On Mon, Jun 26, 2017 at 4:27 PM, Jacob Carlborg via cfe-dev <[hidden email]> wrote:
On 2017-06-26 21:37, scott constable via cfe-dev wrote:
Sorry, I should have clarified. The C/C++ headers are the ones which
cannot be found. For clarity, here's the output of my tool with the -v
flag (I've hidden some sensitive names with ***):

clang version 4.0.0 (tags/RELEASE_400/final)
ignoring nonexistent directory "/***/build-debug/bin/../include/c++/v1"
ignoring nonexistent directory "/usr/include/c++/v1"
ignoring nonexistent directory
"***/build-debug/bin/../lib/clang/4.0.0/include"
#include "..." search starts here:
#include <...> search starts here:
  /usr/local/include
  /usr/include
  /System/Library/Frameworks (framework directory)
  /Library/Frameworks (framework directory)
End of search list.

Both my Xcode clang and my homebrew-installed clang find the headers
through the relative path "../include/c++/v1". This won't be possible
with my libtool unless (a) I move my libtool into the directory where
clang is installed, or (b) I also distribute the C/C++ headers with my
libtool. Both of these solutions is ugly, so I would prefer something nicer.

If only Xcode is installed the headers are available at:

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/8.1.0/include

/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include

This can be verified by running "clang -E  - -v < /dev/null". You'll see the above two paths (or something similar depending on which version of Xcode) are two of the paths Clang will search in.

If the command line tools are installed as well, the headers will be available in "/usr/include" as well. As you can see with the above command, "/usr/include" is one of the paths Clang will search in.

As can be seen in the output from your tool, the paths in /Applications/Xcode.app are not searched in. Since it doesn't find the headers I suspect you don't have the command line tools installed.

Note that even though you can invoke "clang" on the command line to compile code, it doesn't necessarily mean that the command line tools are installed. You can install the command line tools by running "xcode-select --instal". If they're already installed, you'll get a message.

All this trouble with these paths are due to, I believe, Apple wants the Xcode app bundle to be completely self contained and not install anything outside of it unless the user explicitly asks for it. I'm guessing this it to be compatible with the App Store.


--
/Jacob Carlborg

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


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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
On 2017-06-26 22:40, scott constable via cfe-dev wrote:
> Hmmm. I have the same issue as this gentleman:
> https://forums.developer.apple.com/thread/71209. I do have Xcode CLI
> tools installed, but it has installed an older version of libc++ in my
> /usr/include. The installed directory is /usr/include/c++/4.2.1 (I think
> this is either C++03 or C++98), but my libtool expects
> /usr/include/c++/v1. So is this actually an unresolved issue with Xcode?

Hmm, that's interesting. c++/4.2.1 is the old libstdc++ and c++/v1 is
the new libc++, IIRC.

I'm not sure how it should behave. I noticed that if I add the
"-stdlib=libstdc++" flag it will look in the "/usr/include/c++/4.2.1"
directory instead of "/usr/include/c++/v1".

--
/Jacob Carlborg

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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
I just found the rest of the thread here: https://lists.apple.com/archives/xcode-users/2017/Jan/msg00089.html. The upshot is that C++ headers are no longer installed to /usr/include on MacOS. When you install the Xcode command-line tools, the C++ headers are stored in /Library/Developer/CommandLineTools/usr/include/c++/v1. So libtools built on MacOS should look here instead of /usr/include/c++/v1. How can this be done?

On Mon, Jun 26, 2017 at 4:55 PM, Jacob Carlborg via cfe-dev <[hidden email]> wrote:
On 2017-06-26 22:40, scott constable via cfe-dev wrote:
Hmmm. I have the same issue as this gentleman:
https://forums.developer.apple.com/thread/71209. I do have Xcode CLI
tools installed, but it has installed an older version of libc++ in my
/usr/include. The installed directory is /usr/include/c++/4.2.1 (I think
this is either C++03 or C++98), but my libtool expects
/usr/include/c++/v1. So is this actually an unresolved issue with Xcode?

Hmm, that's interesting. c++/4.2.1 is the old libstdc++ and c++/v1 is the new libc++, IIRC.

I'm not sure how it should behave. I noticed that if I add the "-stdlib=libstdc++" flag it will look in the "/usr/include/c++/4.2.1" directory instead of "/usr/include/c++/v1".


--
/Jacob Carlborg

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


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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
On 2017-06-26 22:58, scott constable via cfe-dev wrote:
> I just found the rest of the thread here:
> https://lists.apple.com/archives/xcode-users/2017/Jan/msg00089.html. The
> upshot is that C++ headers are no longer installed to /usr/include on
> MacOS. When you install the Xcode command-line tools, the C++ headers
> are stored in /Library/Developer/CommandLineTools/usr/include/c++/v1. So
> libtools built on MacOS should look here instead of /usr/include/c++/v1.
> How can this be done?

I'm not that familiar with libtools, I've only used the C API in
libclang. In libclang you call the clang_parseTranslationUnit function
and pass in the command line arguments that were passed to your
application. It's possible to add an additional include search path
before calling clang_parseTranslationUnit by adding ["-I",
"/Library/Developer/CommandLineTools/usr/include/c++/v1"] to the command
line arguments array. I'm not sure it's possible to do the same using
libtools.

--
/Jacob Carlborg

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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
Your workaround should work, but it shouldn't be this difficult.

Take a look at https://clang.llvm.org/doxygen/InitHeaderSearch_8cpp_source.html, lines 456-479. Since OSX 10.9, /usr/include/c++/v1 just doesn't exist. Clang should instead use /Library/Developer/CommandLineTools/usr/include/c++/v1 and/or the XCode .app for libc++. Unless anyone disagrees, I'm going to file this as a bug report.

On Mon, Jun 26, 2017 at 5:21 PM, Jacob Carlborg via cfe-dev <[hidden email]> wrote:
On 2017-06-26 22:58, scott constable via cfe-dev wrote:
I just found the rest of the thread here:
https://lists.apple.com/archives/xcode-users/2017/Jan/msg00089.html. The
upshot is that C++ headers are no longer installed to /usr/include on
MacOS. When you install the Xcode command-line tools, the C++ headers
are stored in /Library/Developer/CommandLineTools/usr/include/c++/v1. So
libtools built on MacOS should look here instead of /usr/include/c++/v1.
How can this be done?

I'm not that familiar with libtools, I've only used the C API in libclang. In libclang you call the clang_parseTranslationUnit function and pass in the command line arguments that were passed to your application. It's possible to add an additional include search path before calling clang_parseTranslationUnit by adding ["-I", "/Library/Developer/CommandLineTools/usr/include/c++/v1"] to the command line arguments array. I'm not sure it's possible to do the same using libtools.


--
/Jacob Carlborg

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


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

Re: Libtool search path on MacOS

Xin Wang via cfe-dev
On 2017-06-26 23:40, scott constable via cfe-dev wrote:

> Your workaround should work, but it shouldn't be this difficult.

I agree.

> Unless anyone disagrees, I'm going to file this as abug report.

Please do.

--
/Jacob Carlborg

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