[llvm-dev] LibC++ tests in tree

[Eric Fiselier via llvm-dev]

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

That's probably a good guess. I haven't taken the time yet to understand
why libc++ links to the libraries that it does. Optimally the test suite
should link the tests exactly the same way clang does with -stdlib=libc++.
I'm working on changes to clang to help us achieve this.

@Renato: What OS are you having issues on? I'll turn off linking
"-lrt" right away.


> 2. Shouldn't we disable the "en_US" locales if they cannot be used,
> just like the "fr_FR" ones?

Yes we should. Do you have any information about how many tests need this
treatment?

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

That might be more tricky because I imagine the expected results depend
on the fact that "en_US" is being used for a lot of tests. I think
we should avoid using the "default" locale in all of the tests.

/Eric


On Mon, Sep 7, 2015 at 1:51 PM, Adhemerval Zanella via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
>
> 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
>>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev