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
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 >
> 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
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
On 8 September 2015 at 16:35, Jonathan Roelofs <jonathan at codesourcery.com> wrote:> 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