Thank you!

@ilya-biryukov, gentle ping. I'd like to patch this for 7.0.0 in Gentoo. Do you think my patch would be good enough, or do you expect to submit something else soonish?

...and unless I'm mistaken, this commit is responsible for both changes (that is, I need to apply all of this patch to make tests pass at its point).

Apparently the first change changing the completion results is:

Ai, sorry about that. Uploaded the proper diff now. I suppose it's not going to make it for 7.0.0 anymore, so it's not a priority. I'll try to bisect it today once I finish testing RC3.

Ping.

I don't have a strong opinion here.

Is LLVM_CONFIG dropped from cache here? I suspect the warning might fire for everyone who has LLVM configured.

Given the answer on binutils thread, let's commit this. If it causes any unexpected issues, hopefully we'll learn about them during the RC testing.

Adding @tejohnson as owner of gold plugin.

No problem. Thanks for reviewing both of those patches!

Let's query @hans 's opinion on this. ~Jan 2019 sounds like it may still be relevant to LLVM 7.

Also, are you maybe aware of how soon is this going to hit binutils users? It kinda looks like a ticking time bomb, so maybe it would be worth fixing it for LLVM 7 release as well.

I don't really know BFD plugin API, so I don't know if this could have any implications (I suppose upstream's answer may be helpful there). However, I don't think it likely to cause any real trouble.

Makes sense. Thanks!

Looks good, thanks!

I don't think this could break anything. I presume you've tested it though.

In D47817#1155788, @Lekensteyn wrote:

In D47817#1155717, @mgorny wrote:

This would be the first user of pkg-config here. I am not sure if this would be the best fix. Usually you cannot (easily) recompile libc and override it, but for external libs such as libtirpc this should be more doable (I think).

I don't think libtirpc's include path is expected to be predictable by design. I think it's something distro maintainers have to choose to avoid collision with headers that (used to be) installed by glibc. In any case, I can't think of a better solution than pkg-config here (libtirpc doesn't come with CMake modules).

On Arch (libtirpc-1.0.3-2), Debian (libtirpc-dev 0.2.5-1.2 in sid), Gentoo (libtirpc-1.0.3), the include files happen to be installed in /usr/include/libtirpc, so it seems pretty consistent. So you could consider writing a cmake/Modules/FindLibtirpc.cmake module that looks like:

# sets Libtirpc_FOUND Libtirpc_INCLUDE_DIRS

find_path(Libtirpc_INCLUDE_DIR
  NAMES rpc/xdr.h
  PATH_SUFFIXES tirpc
)
include(FindPackageHandleStandardArgs)
find_package_handle_standard_args(Libtirpc REQUIRED_VARS Libtirpc_INCLUDE_DIR)
if(Libtirpc_FOUND)
  set(Libtirpc_INCLUDE_DIRS ${Libtirpc_INCLUDE_DIR})
endif()

then you can use find_package(Libtirpc) without depending on pkg-config.

In D47817#1155637, @Lekensteyn wrote:

Hi, thank you for the patch. First a disclaimer, I am not familiar with this RPC API at all.

Ping.

Ping. This is necessary to resolve https://github.com/google/sanitizers/issues/974 and fix tests on systems which don't enable all the backwards compatibility cruft (Arch, Gentoo). See also D47817 as necessary dependency.

Gentle ping.

Gentle ping.

Gentle ping.

Erm, louder ping?

Erm, louder ping?

Good catch! LGTM.

To add a real use case broken by this: Gentoo prior to 17.1 (which includes most of existing installs) used /usr/lib -> lib64 symlink. The canonical LLVM install path for Gentoo is:

…at the cost of breaking CMake, and having to hack LLVM and CMake to make it work again. And I'm pretty sure sooner or later this realpath use will break somebody's use case. Think of a simple example of someone using a temporary symlink in path to relocate LLVM install. By using realpath, you're effectively replacing the canonical location with possibly temporary current location that may no longer be valid afterwards.

Works just fine. Note that find_package documentation actually mentions scanning locations relative to PATH.

Gentoo also supports installing multiple versions (in /usr/lib/llvm/X), and I have never seen any problems close to what you're describing. We're just putting the appropriate bin/ directories in PATH, and CMake finds its files just fine (relatively to PATH). So why do you need a lot of symlink magic to achieve the same effect?

I don't think I agree with this change. Unless I'm missing something, Debian is using a install layout that is broken by design, and you're now attempting to workaround that by adding symlinks and realpath hacks that are supposed to make the broken design somewhat incidentally work, if only someone doesn't miss one of the fragile connections and accidentally break it.

For the record, this has been fixed upstream: https://github.com/sphinx-doc/sphinx/pull/4282. However, I don't know which release version (if any) has the fix.

In D42274#982263, @jyknight wrote:

But of course nbjoerg will complain because it will break all the people who run clang outputting to Tektronix 4012 graphics terminals which can't parse vt100/ansi escape sequence syntax. And I don't have the will to argue the point.

I've based this change on an earlier fix to lldb when that project started using LLVMTestingSupport.

I think you'd want a definition list instead then. But I haven't tested if they can be nested inside option lists.

W dniu nie, 08.04.2018 o godzinie 00∶13 +0000, użytkownik Zachary Turner
napisał:

Lgtm

Well, my idea was to list the standards one per line (like on GCC manpage), and then the '(deprecated)' comments would probably stand out enough to apply to a single line. Also, FWICS the gcc manpage simply lists which aliases are deprecated in the description text. But skipping them entirely also works for me.

To be honest, I find those '(deprecated)' confusing — the user may mistakenly assume that it's about all values rather than the alias.

Works fine, thanks a lot! Note that I haven't tested crossdev or anything special, just regular multilib.

I'm sorry, I see the problem now — the diff generated by Phabricator does not include the empty files x_x (seriously, this thing keeps surprising me in how broken it could be). I'm going to try again with correct file set tonight or tomorrow. If you could send the complete patch (preferably -p1 if you have one) to mgorny AT gentoo.org, that would also be helpful.

Well, it's better:

To be honest, I don't really know. But since we're not installing it straight to /usr, I suppose that's not a problem we need to solve right now.

Ok, that's a problem. I think we really ought to consider all possibilites of sysroot first, and either do not fall back to main system at all or do that only if sysroot doesn't have any install at all. Basically, it is important that we don't break non-Gentoo sysroots, even when running on top of Gentoo.

Ok, I've tried it on top of clang-6.0.0 and I get the following test failures:

If that's not a problem, then the more tests, the merrier ;-). Preferably something specific to crossdev would be helpful, given this is a new use case, and/or something that would actually have directory mismatches with CURRENT entry name (i.e. that wouldn't have worked before).

Thanks. Besides that one tiny nit, looks good at a first glance. I'll test it tomorrow or the next day (but only for the most basic use, sorry).

@eugenis, updated.

Aye, sorry, I confused it with generated config ;-). It looks sane to me.

I don't see why not but I'm not sure if it has any value by itself. FWICS, LLVM_DYLIB_COMPONENTS is not used anywhere in cmake/*.

Yes, full standalone.

I can't test this right now but please make sure not to break linking to split shared libraries without dylib.

Thanks for the review. As for the -Wl,-z,origin part, I'd rather leave that alone unless we have a clear indication that either it is not necessary for any of the supported FreeBSD and DragonFly BSD versions, or that it can be passed unconditionally without breaking any of the supported systems (and which linkers accept it).

@rnk, could you confirm the rebased patch? I'm not sure if I should override InputKind::RenderScript as well.