Can LLVM be built so that its 'lib' directory has higher priority by default?

[Ces VLC]

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?).

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?).

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.

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.

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...

Thanks!

César




On Tue, Jan 22, 2019 at 1:53 AM Ken Cunningham <
ken.cunningham.webuse at gmail.com> wrote:

> Hi,
>
> 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.
>
> 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.
>
> 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.
>
> 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 <https://trac.macports.org/ticket/57612>.
> 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.
>
> 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).
>
> See <
> https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/Portfile>
> and <
> https://github.com/macports/macports-ports/blob/master/lang/llvm-7.0/files/9001-macports-libstdcxx.diff>
> for a clue as to how someone might proceed if they wanted to try that.
>
> Maybe there are easier ways I haven't thought of here -- this is just what
> came to mind between events at work.
>
> Hope this at least gets you started !
>
> Ken
>
>
>
> On 2019-01-21, at 1:54 PM, Ces VLC wrote:
>
> > Hi,
> >
> > 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
> >
> > The main purpose is that I want that the LLVM libc++ is always used by
> default, instead of the MacOS one.
> >
> > 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.
> >
> > How can I build LLVM with this behavior?
> >
> > Thanks a lot!
> >
> > César
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-users/attachments/20190122/6ab9c411/attachment.html>