This reverts commit f9146ccbe940d8b8eb15e7686a511a28eb0abc6b
([libc][bazel] explicitly use system-provided errno in Bazel builds.
(#130663))
This change causes problems in Bazel builds where system errno is set to
non-zero before the tests even begin to run - see PR #131650 for the
disucssion on how to address this.
The Windows toolchain needs to build libc targets in order to support
libc++. Currently, some targets fail to resolve, due to non-exhaustive
select statements, not accounting for Windows builds.
This change adds clauses to select statements so that Windows builds can
proceed.
Additionally, `__support_osutil_exit`, is configured to pass nothing to
`srcs` for non-Linux builds. `__support_osutil_exit `is unconditionally
included in the transitive dependencies of `extern_libc_shared`.
---------
Co-authored-by: Brian Ledger <brianpl@google.com>
See PR #130327 for background and motivation. This change expands the
libc_support_library and libc_function rules to create filegroups that
allow building a collection of llvm-libc functions together, from
sources, as a part of a single cc_library that can then be used by the
downstream clients.
This change also adds an example use of this macro under
libc/test/BUILD.bazel to confirm that this macro works as expected.
Addressing the comments from PR #130368 review. Since Bazel builds are
effectively overlay mode, switch to explicitly setting
-DLIBC_ERRNO_MODE=LIBC_ERRNO_MODE_SYSTEM configuration option, so that
unit tests and release builds are consistent. Verified that all the unit
tests pass with this flag specified.
This shouldn't really be a "libc_function" since it can be used as a
dependency of various other support libraries and functions, and doesn't
correspond to a well-defined endpoint that the users may want to
explicitly depend on (if they depend on it implicitly through a
libc_function whose implementation relies on errno, the dependency will
be pulled in normally). Remove special handling for "errno" in the Bazel
test rules.
This is one more cleanup step unlocking the plan outlined in #130327
Use it instead of libc_support_library macros for all helper libraries
that are used for unit tests. See #130327 for the rationale why we want
to do this. With this change, we can additionally ensure that no
testonly library will end up being a dependency of production libraries.
* strcpy doesn't need to depend on memcpy
* qsort_test_helper has been generalized and doesn't need to depend on
qsort.
This is a small cleanup to unblock the work outlined in #130327.
This involved a little bit of yak shaving because one of the new tests
depends on MPC, and we didn't have targets for it yet, so I ended up
needing to add a similar setup to what we have for MPFR.
Previously telemetry was optional at build-time in such a way that none
of it was built at all, but llvm/llvm-project@159b872b37 changed that
and now it's optional in a different way so we need to have it available
in the bazel BUILD graph.
The downstream build was having trouble transforming the previous list
comprehension, but it works on this one. I guess it just needs to look
like a proper target.
Add targets and tests for strfromf, strfromd and strfroml.
No idea why the standard committee decided that the long double function
should be "strfroml" instead of "strfromld" which would match "strtold"
and leave them space to add string from integer functions in future.
Adds targets for the stdbit functions. Since the names follow a strict
pattern, this is done via list comprehensions. I don't want to handwrite
all 50.
Details:
- Previously, we used the LLVM_BUILD_TELEMETRY flag to control whether
any Telemetry code will be built. This has proven to cause more nuisance
to both users of the Telemetry and any further extension of it. (Eg., we
needed to put #ifdef around caller/user code)
- So the new approach is to:
+ Remove this flag and introduce LLVM_ENABLE_TELEMETRY which would be
true by default.
+ If LLVM_ENABLE_TELEMETRY is set to FALSE (at buildtime), the library
would still be built BUT Telemetry cannot be enabled. And no data can be
collected.
The benefit of this is that it simplifies user (and extension) code
since we just need to put the check on Config::EnableTelemetry. Besides,
the Telemetry library itself is very small, hence the additional code to
be built would not cause any difference in build performance.
---------
Co-authored-by: Pavel Labath <pavel@labath.sk>
