Our stale file regeneration logic broke with Bazel 6.4.0, and I suspect it was
caused by this change: https://github.com/bazelbuild/bazel/pull/19534 Our logic
assumed that any target with a `CcInfo` provider must have `hdrs` and
`textual_hdrs` attributes, but it seems that this is no longer true for
`cc_proto_library` starting with Bazel 6.4.0. The fix is just to use `getattr`
and treat the item as an empty list if it's missing.
PiperOrigin-RevId: 575473886
setup-gcloud doesn't honor the environment variables set by setup-python, so we need to manually set CLOUDSDK_PYTHON before running it.
PiperOrigin-RevId: 578674246
These tests were right near the threshold for disk space on default runners, and recently got pushed over (~18G). The cheapest large runner has 150G of SSD storage, and won't likely hit this issue again.
PiperOrigin-RevId: 572596499
This has caused repeated issues due to the fact that it checks the entire repo. Most recently, it decided to complain about a typo in a file that hasn't been touched in 5 years.
PiperOrigin-RevId: 540356791
* Update upb dep to the latest 23.x commit
* Fix objectivec test failure in Bazel 6+.
This fix works in Bazel 5 and 6, but the original `import pddm` only works in Bazel 5. This is preventing our upgrade to Bazel 6 that will reduce our mac flakes in CI.
PiperOrigin-RevId: 543565397
* Bump heap size for linkage monitor tests
Follow-up from #12953 to update to `32.0.1` to fix an issue on windows:
https://github.com/google/guava/releases/tag/v32.0.1
The underlying issue likely does not affect protobuf as it does not appear to (directly) use the affected `Files.createTempDir` or `FileBackedOutputStream` code which was apparently broken on Windows in `32.0.0`.
Seems best to update anyway.
(cherry picked from commit c95ebb7bd8)
Our automation can't currently update release branches, so we need to enable staleness tests as presubmits to force manual regeneration.
PiperOrigin-RevId: 540094169
- Do some minimal sanity testing on every PR
- Only run the staleness tests on a daily schedule or explicit runs.
- Add 23.x to the checks
PiperOrigin-RevId: 537952151
Hi,
It seems that until last year, the logic behind `PROTOBUF_USE_DLLS` was for Windows (MSCV) only. It was changed to all platforms here in 5a0887fc65
Last month, the generated pkg config files were updated to reflect the protobuf build-time value of `PROTOBUF_USE_DLLS` as it was indeed noted that it changes the ABI. This was done in https://github.com/protocolbuffers/protobuf/pull/12700 In the commit message it is mentionned that most likely we shall rather have a stable ABI.
Finally in https://github.com/protocolbuffers/protobuf/issues/12746 which at some point mentions https://issuetracker.google.com/issues/283987730#comment7 where a Google employee hits the linker issue:
```
undefined reference to `google::protobuf::internal::ThreadSafeArena::thread_cache_'
```
which denotes a mix of some .o or libs built `PROTOBUF_USE_DLLS` defined and some others build with `PROTOBUF_USE_DLLS` undefined, resulting in ABI incompatibilities.
I also hit this issue while trying to include protobuf in a corporate environment using it's own proprietary build system in which it is expected that .a and .so use a compatible ABI.
From my own understanding, ideally we should always use `thread_local` variables, but experience has shown that:
- old iOS (iOS < 9) didn't seem to accept `thread_local`, leading to the `GOOGLE_PROTOBUF_NO_THREADLOCAL` macro later renamed `PROTOBUF_NO_THREADLOCAL` which allowed to disable this, but it is not set anywhere in the protobuf code base. Also I doubt you still want to support such old iOS now, so maybe you should consider removing all `PROTOBUF_NO_THREADLOCAL` related code paths (this pull request doesn't do this).
- MSVC's DLL interface doesn't seem to accept exporting thread local variables (at least from what I understood, I know absolutely nothing about the Windows ecosystem), yet we can "hide" a thread local variable in a static function using a thread local variable. However in that case the access to TLS variable is not inlined, leading to worse performances, this hack shall be done only for Windows (actually when using MSVC) *AND* we build a shared library.
- In all other cases, a classical `thread_local` shall be used, no matter if we build a static or a shared library. In particular on Linux which I guess is the target Google cares the more about for its own production. This pull request achieves this.
Am I right in my conclusion ?
Closes#12983
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12983 from Romain-Geissler-1A:stable-abi-use-dll-non-windows dc23ff50f6
PiperOrigin-RevId: 538230923
This additional if is necessary as of abseil 20230125.3 when abseil is consumed via add_subdirectory,
the abseil_dll target is named abseil_dll, while if abseil is consumed via find_package, the target is called `absl::abseil_dll` .
Once https://github.com/abseil/abseil-cpp/pull/1466 is merged and released in the minimum version of abseil required by protobuf, it is possible to always link `absl::abseil_dll` and `absl::abseil_test_dll` and remove the if.
You may wonder how linking worked at all before when `protobuf_ABSL_PROVIDER STREQUAL "package"`, as `abseil_dll` was not an imported target defined by `find_package(absl)`. The reason behind this is that if a name that is not an imported target is passed to `target_link_libraries`, it is just regarded as a C++ library name. So, in the end the `abseil_dll` library was correctly linked, simply all the transitive usage requirements defined by the `absl::abseil_dll` target were not propagated, that could lead to compilation errors if abseil was compiled with the `ABSL_PROPAGATE_CXX_STD` CMake option enabled.
Closes#12978
COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/12978 from traversaro:patch-1 39dd074281
PiperOrigin-RevId: 537990391
This is a macro on some (older) versions of GCC, and macOS, and Windows. Sigh. I moved the `#undef` block to a common section. I also took the opportunity to add a regression test for all these macros that need to be `#undef`'d.
Part of the work for googleapis/google-cloud-cpp#8125
Closes#12903
PiperOrigin-RevId: 535649278
Mike Kruskal
Mike Kruskal
Adam Cozzette
Joshua Haberman
Jie Luo
Protobuf Team Bot
zhangskz
Chad Wilson
Matt Fowles Kulukundis
WenTao Ou
Matt Kulukundis
kang jinci
ericsalo
Thomas Van Lenten
Romain Geissler @ Amadeus
Protobuf Team Bot
Silvio Traversaro
Carlos O'Ryan