glibc supports versioning, so it's possible to build against older
version and run against newer version. This is sometimes relied on
in practice, e.g. in Fuchsia build we build against older sysroot
(equivalent to Ubuntu Trusty) to cover the broadest possible range
of host systems, but that doesn't necessarily match the system that
binary is going to run on which may have newer version, in which case
the compile test used in curr_symbol is going to fail. Using runtime
check is more reliable. This is a follow up to D56702 which addressed
one instance, this patch addresses all of the remaining ones.
Details
- Reviewers
ldionne EricWF - Group Reviewers
Restricted Project - Commits
- rG80ef4126b100: [libcxx] Use runtime rather then compile-time glibc version check
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
I think the correct way of handling this would be to define a Lit feature that expresses the fact that we're running on a newer system but we compiled on an older system. Like the reverse of what we do for back-deployment on macOS. I know this isn't what we did in D56702, but that strikes me as the wrong approach. It seems to me like this is something we want to tackle at the test driver level, not inside the test per-se. Am I missing something?
We could do it in lit but I'm not sure if it's going to be simpler or cleaner. We would need to find out the location of glibc which can vary across distributions and then parse the output of libc.so.6 --version which is more work than what we're doing in glibc_version_less_than. If the test is being executed on a remote system, this needs to be done over remote protocol which may complicate things even more. Then we need to pass that version to each test where the logic is likely going to be very similar what I've done in this patch.
I checked with @mcgrathr and pointed out that we could use getconf GNU_LIBC_VERSION to get glibc version which is a command-line equivalent of confstr invocation used by glibc_version_less_than. I still think that the current implementation is simpler, but I can try to rewrite it in lit if you prefer.
I guess I don't really like this sort of mangling of the test suite, however looking at other locale tests, it seems like we already do a lot of it. Furthermore, my lit suggestion would basically allow XFAILing the tests, which isn't what you're after. So I guess this is okay.
How far back do you support glibc? It would be nice to have a clear bound on this.
Thanks!
How far back do you support glibc? It would be nice to have a clear bound on this.
2.17 which was shipped with Ubuntu 14.04, this patch is sufficient so I don't think we should need further changes.
This broke the tests on MacOS: https://buildkite.com/llvm-project/libcxx-ci/builds/74#5d6d5ad0-27cc-4de5-b6d7-1b7b04d49464
libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp | ||
---|---|---|
129 | On non-glibc, this changed the wsep from L' ' to L'\u00A0' if I read this correctly. |
libcxx/test/std/localization/locale.categories/category.monetary/locale.moneypunct.byname/thousands_sep.pass.cpp | ||
---|---|---|
129 | Thanks for catching this, addressed in rG4424d2428aebd3537d3f5a3625acb65edfb5d11f. |
On non-glibc, this changed the wsep from L' ' to L'\u00A0' if I read this correctly.