This causes a test failure with non-standard CLANG_RESOURCE_DIR:

(note that I don't mind removing the llvm-config bit for it; but we need the cache variable to stay)

This is going to break Gentoo. We're relying on the ability to specify LLVM_MAIN_SRC_DIR to provide unpacked LLVM sources with gtest. Without that, I don't see how we can use tests.

Well, I've just checked gcc-config sources and it seems that it sources the file through bash, and gets the resulting ${CURRENT}. While I don't think we ought to do complete bash support here, I guess allowing the same degree of whitespace bash does makes sense.

Is there any specific reason you need this? Since the file is autogenerated, I don't think it matters very much to allow extra whiespace. But then, I do not think it hurts, so feel free to do it. The code LGTM; note that I haven't tested it, however.

D31864 covered all that was needed for Gentoo, and I lack the knowledge to push the full split properly forward.

See also: D25568. It served the same goal, except that it didn't require the user to explicitly indicate which runtime is enabled in his compiler (i.e. supported clang with compiler-rt by default out of the box). I'm not sure if having both makes sense now; however, I feel like having to figure out whether the compiler is using compiler-rt or libgcc and setting flags appropriately would kinda suck.

See also: D23758, for SphInx + doxygen + relevant options.

Well, I can confirm that the hack works for me. Not that I like it but if it's meant to be only temporary, I'm fine with any solution that works.

In D31367#714305, @beanz wrote:

Please revert your patch. It is *not* the right solution and is masking underlying problems.

In D31367#713472, @labath wrote:

We don't depend on the RuntimeDyld component of llvm directy -- we only use it indirectly through the ExecutionEngine component. Shouldn't that be reflected as a dependency in the build system somehow, so that the former can be pulled in directly ?
RuntimeDyld is listed as a dependency of ExecutionEngine in lib/ExecutionEngine/LLVMBuild.txt, but that does not seem to be reflected in the cmake? Is that a bug on the llvm side?

Needed to rebase again.

Rebased. Ping. Now that we have lit tests for builtins, it would be really useful for us to be able to build them without having to enable sanitizers.

Reopening since it has been reverted.

In D30997#704406, @beanz wrote:

@mgorny, we should only support this on shared libraries that we intend as vended libraries, not all libraries. For example we don't really want to support the CMake BUILD_SHARED_LIBS option's libraries as vended libraries on any platform.

1. Any reason not to use this for all shared libraries?
2. AFAICS --default-symver is present on FreeBSD as well.

I'm sorry, I've completely forgot that the path contains version number. In this case, it indeed probably doesn't make much sense to add rpath for that.

Ping II.

@beanz, a little more of a ping since you've specifically asked for it ;-).

A gentle ping.

PIng.

Ping.

Another ping. Since 4.0.0 final has been tagged, I think we should get back to working on this. @compnerd, any suggestion how to proceed here?

First of all, thank you for doing this! This was long overdue ;-).

In D30773#696301, @EricWF wrote:

There seem to be a couple cases where it's non-trivial to convert the output from bytes to str. I'll look into this further and update.

I'm sorry but what is the exact use case for this? I'm not exactly against having a function like this but 'realpath' logic is the kind of thing people frequently abuse, so I'd rather make sure we don't end up accidentally replacing 'canonical' paths provided by the user with 'real' paths.

@compnerd, I presume that the option would do nothing when using -rtlib=libgcc, correct? Or do we support combining libgcc with another unwinder?

If I read the git correctly, the change that forbid defining builtins was initially made in rL64639. @doug.gregor, any chance you could help us over here? Is clang supposed to unconditionally reject those definitions, and are we supposed to always work-around it in compiler-rt, or should we consider adding some additional switch to allow them in clang?

Le gentle ping.

LGTM modulo the test match split. But please wait for someone who has been longer here to confirm.

Thanks. The -L tests look good, -rpath is not perfect but I don't think you can improve it without additional changes to the Driver.

Following @labath's suggestion, I've changed my approach a little. Now I'm using PATH lookup only for CC/CXX, while for remaining tools I'm using either llvm_tools_dir or lldb_tools_dir appropriately.

In D30025#678462, @theraven wrote:

This code is working around something that's probably a clang bug. It would be better to fix the clang bug than add more complex workarounds.

I would like to point out that if you proactively reject all paths with spaces, you wouldn't be able to add additional tests that would test support for paths with spaces ;-). While I agree that we should avoid spaces whenever possible, I think it would be reasonable to add tests for paths with spaces wherever we expect them to be well-supported and want to avoid regressions.

I've opened http://bugs.llvm.org/show_bug.cgi?id=31964 to track this further. I don't really have time to look into it in more detail at the moment.

Ping.

Le gentle ping.