[PATCH] D47817: [sanitizer_common] Fix using libtirpc on Linux

Michał Górny via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Mon Jul 9 05:58:55 PDT 2018


mgorny added a comment.

In https://reviews.llvm.org/D47817#1155637, @Lekensteyn wrote:

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


Me neither. I'm only familiar with this particular issue because it's what we're hitting a lot recently.

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

> I'm not comfortable with adding the tirpc include path to the default include path and stripping `-nodefaultlibs` either, would this approach work for cross-compilation?

I can't see why not — I suppose most of cross-compilation environments already redefine pkg-config paths appropriately. Even if it wouldn't, this shouldn't cause a regression because the 'default' case (RPC headers sraight in default paths) is not affected, and libtirpc case never could have worked.

As for `no-defaultlibs`, that is only stripped for the purpose of `check_include_file` and is afterwards restored. I can't think of a reason it would fail with stripping, and it certainly fails for me if it's not stripped.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D47817





More information about the cfe-commits mailing list