[llvm-dev] LibC++ tests in tree

Adhemerval Zanella via llvm-dev llvm-dev at lists.llvm.org
Mon Sep 7 12:51:25 PDT 2015



On 07-09-2015 12:32, Renato Golin via llvm-dev wrote:
> Folks,
> 
> I'm running the libc++ tests in tree [1] and I'm seeing two class of errors:
> 
> 1. -lrt is used, but there is no such "librt.a" in the path. Results
> are that some symbols are not found, or that the DSO object wasn't.
> Adding a symlink in build/lib/librt.a to
> build/clang/3.8.0/lib/linux/libclang_rt.builtins-aarch64.a worked.
> 
> 2. "collate_byname failed to construct for en_US.UTF-8". My box is
> setup with locale as "en_GB.UTF-8" but it also has "en_US". Changing
> the locale of the machine to "en_US" didn't help either. There are
> other locale tests ("fr_FR") that get disabled if you don't have that
> locale, but not the "en_US".
> 
> So, my questions:
> 
> 1. Is "librt.a" the official name when we install LLVM+RT? I did try
> "ninja install" after building Compiler-RT and got nothing of the
> sort. However, libclang_rt.builtins-aarch64.a is at clang/... and I
> got libc++ and libunwind shared objects at build/lib. Is this just an
> installation issue? Or the wrong assumption by the tests? Maybe we
> should just add the symlink whenever RT is built?

It should not for POSIX targets, since librt is the POSIX.1b Realtime 
Extensions library.  The standard does not define where it *should* be
implemented, so the implementation are free to either provide different
libraries (as for GLIBC) or pack in only one (Android, musl, etc.).

My guess is libc++ are requiring to link against -lrt to get the
clock_{get,set}time function and since for GLIBC 2.17+ they not
any longer on librt.so (but rather on libc.so) making the link 
from librt.a seems to work.

Correct solution IMHO would be to link against the C-runtime.

> 
> 2. Shouldn't we disable the "en_US" locales if they cannot be used,
> just like the "fr_FR" ones? Shouldn't we try to enquire what's the
> default locale of the system and use that instead? But for the time
> being, what would be a quick fix to make the tests run and pass for
> now?

Does the test require the 'en_US' locale or is it just to test load
a different locale? If the latter we can try we any different system
locale or just bail if there is no extra locale installed.

> 
> cheers,
> --renato
> 
> 
> [1] http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-prototype
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 


More information about the llvm-dev mailing list