LibC++ tests in tree

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?

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?

cheers,
--renato

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

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.

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

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

Linux. Thanks!

I got the AArch64 bot green
(http://buildmaster.tcwglab.linaro.org/builders/clang-cmake-aarch64-prototype)
by applying these two fixes.

Another error that will not be fixed by just removing -lrt are the
missing symbols that are present in libgcc/compiler-rt, since, because
they're using no std libs, neither are being included.

So, either I have to add the builtins.a in LDFLAGS, or you have to add
the dependency on either libgcc or compiler-rt on the tests
themselves.

Let me know when you have the fixes, so I can remove the symlink and
let the bot in a vanilla state.

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?

23, logs attached.

It'd be good to have *some* locale tests, though. Maybe spread over
the most common ones, or use "C" or "POSIX" or something that all
environments are required, for the tests that make no difference.

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.

Or, if possible, try to set up the locale before running the tests,
though, I'm not an expert in locales, so I'm not sure how to do that.
:slight_smile:

cheers,
--renato

nohup.zip (2.74 KB)

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

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?

It seems -lrt wasn't related to compiler-rt after all. But if it were,
I'd say the installation process should understand the difference
between host and target, multilib and multiarch.

Right now, the option --rtlib is doing nothing useful, but it could
also, from the triple, find the right lib and link to it
automatically.

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

I'd expect the C++ library to also have some detection mechanism, at
least to show that error message.

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.

The detection could be in the test itself, as a prepare task before
running, in the C++ code, so that it executed on the same target as
the tests themselves.

cheers,
--renato