[llvm-dev] LibC++ tests in tree

[Jonathan Roelofs via llvm-dev]

On 9/7/15 9:32 AM, Renato Golin 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?

I think that adding such a symlink breaks multiarch installs... 
Rhetorically speaking, what arch would `lib/clang/3.8.0/linux/librt.a` 
support for a compiler with more than one backend included?

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

They should have `REQUIRES` lines like this one: 
https://github.com/llvm-mirror/libcxx/blob/60784f62deefe20952cabe220eb3f14b20c5e659/test/std/input.output/stream.buffers/streambuf/streambuf.members/streambuf.locales/locales.pass.cpp#L10

Those strings get populated into the available features set here: 
https://github.com/llvm-mirror/libcxx/blob/60784f62deefe20952cabe220eb3f14b20c5e659/test/libcxx/test/config.py#L239

One thing to note about this locale detection stuff is that it relies on 
testing for the locales from python, which might give different results 
than via c++ (I don't know of an example of this, but it could be 
plausible).

The other caveat is that the locale detection happens on $host, but the 
actual tests could be running on $target. If $host != $target, then 
detecting it in python is almost definitely the wrong thing to do.


Cheers,

Jon


>
> cheers,
> --renato
>
>
> [1] http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-prototype
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded