<div dir="ltr">Thanks a lot for all the provided info. Yes, I'm building libc++ and libc++abi, but I'm doing it in-tree (ie: inside llvm/projects, so that libc++ and libc++abi are being built at the same compile invocation as the whole LLVM). And one thing that I find really confusing is that the LLVM build system treats libc++ in a very weird way (or at least weird from my point of view). Yes, it builds everything... but clang is linked against the system libc++ instead of the one in llvm/projects (I'd expect the contrary: if you build libc++ is because you will be using it, and if you will be using it, why wouldn't clang be linked against it?).<div><br></div><div>To make things more confusing, when running the tests, it seems that the newly just-built libc++ is the one being tested (why test the newly built if clang is linked against the system one?).<br><div><br></div><div>I usually build LLVM in several "stages" (like GCC does), so that at the end I'm using a LLVM built with the same version (just for pedantic correctness if you wish). And I usually find that I'm able to force the clang/clang++ drivers to be linked against the libc++ compiled in the previous "stage" (by telling so through brute-force CXXFLAGS or similar variables at build time), but not with the one being compiled in the current stage.</div><div><br></div><div>At the end, the only conclusion I arrive to is that libc++ and libc++abi are treated as second-class citizens by the LLVM build tree, as if they were libraries that you are building but without wanting to use them (?!), so maybe the only possible approach is the one followed by MacPorts, with each "stage" being something like: first build libc++ and libc++abi (out of tree), and then build LLVM with the proper brute-force environment variables in order to link against them.</div></div><div><br></div><div>Obviously LLVM doesn't consider the scenario of developers trying to isolate system dependencies (my case), so I think my best bet is going to imply some chroot-ing...</div><div><br></div><div>Thanks!</div><div><br></div><div>César</div><div><br></div><div><br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 22, 2019 at 1:53 AM Ken Cunningham <<a href="mailto:ken.cunningham.webuse@gmail.com">ken.cunningham.webuse@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
WIth the way MacPorts builds llvm/clang, libc++ is not actually built or installed in the directory you mention. It could be -- the source is there -- but it isn't. We just use the source for the llvm build, and install the headers, but don't build or install libc++ that way.<br>
<br>
The MacPorts-sanctioned way to do what you want to do is to use the libcxx port, and if you look at the variants, there is a "replacement" libcxx that forces a new libcxx to install in "/usr/lib/". This is presently set to be the libc++ that comes with llvm-5.0. I have personally built the libc++ that corresponds to llvm-7.01, but haven't yet pushed that through as I've been working with the libcxx port quite a bit lately and didn't want to do too many changes at once.<br>
<br>
Certainly if I was going to do that on a current system I'd back up my libc++ first, I'd bump the libcxx port to the 7.0.1 release, and then cross my fingers :> It will almost certainly work fine, but you need a method to get the original libc++ and libc++abi back in place in case of gremlins, because if there is a gremlin, your system won't boot.<br>
<br>
It is possible to adjust clang's library search paths, but it's not quite as easy as we thought. Ideally you should be able to pass -syslibroot, but that didn't really work out <<a href="https://trac.macports.org/ticket/57612" rel="noreferrer" target="_blank">https://trac.macports.org/ticket/57612</a>>. Even if you did alter and SDK and use isysroot to build against a different libc++, you'd wind up using the one in /usr/lib at runtime. <br>
<br>
If you dig into the clang source code, you can quite easily find where the behaviour to look for libraries is handled;  there is a custom modification to clang on MacPorts where we allow it link against a different libstdc++ by passing in an added stdlib Marcus made up. So it would be possible, I believe, to set up a clang modification to use another custom stdlib (ie -stdlib=myspeciallibc++) that uses directories and headers you choose. It would be a slightly "advanced" project to do that, but do-able, I believe, in a day or three (or less, if you eat this stuff for breakfast). <br>
<br>
See <<a href="https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/Portfile" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/Portfile</a>> and <<a href="https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/files/9001-macports-libstdcxx.diff" rel="noreferrer" target="_blank">https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/files/9001-macports-libstdcxx.diff</a>> for a clue as to how someone might proceed if they wanted to try that.<br>
<br>
Maybe there are easier ways I haven't thought of here -- this is just what came to mind between events at work.<br>
<br>
Hope this at least gets you started !<br>
<br>
Ken<br>
<br>
<br>
<br>
On 2019-01-21, at 1:54 PM, Ces VLC wrote:<br>
<br>
> Hi,<br>
> <br>
> I'm building LLVM 7.0.1 manually (well, following the MacPorts port file, but doing it manually), and I'm aiming for getting a clang/clang++ that by default looks for libs in the LLVMHOME/lib directory (where LLVMHOME is the installation prefix used when building LLVM) before looking at /usr/lib and at /usr/local/lib<br>
> <br>
> The main purpose is that I want that the LLVM libc++ is always used by default, instead of the MacOS one.<br>
> <br>
> Of course I know I can add LLVMHOME/lib as a -L option passed to clang++, but I want it to be a default rather than a -L option, because some packages come with broken Makefiles that overwrite any tuning that you wish to perform through environment variables such as LDFLAGS or CXXFLAGS.<br>
> <br>
> How can I build LLVM with this behavior?<br>
> <br>
> Thanks a lot!<br>
> <br>
> César<br>
<br>
</blockquote></div>