Comparing changes

23.x 202305251532

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

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 abseil/abseil-cpp#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=#12978 from traversaro:patch-1 39dd074 PiperOrigin-RevId: 537990391

PiperOrigin-RevId: 537042088

[23.x] Backport some changes necessary for google-cloud-cpp resp. conda-forge

…orms (#12983) 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 5a0887f 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 #12700 In the commit message it is mentionned that most likely we shall rather have a stable ABI. Finally in #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=#12983 from Romain-Geissler-1A:stable-abi-use-dll-non-windows dc23ff5 PiperOrigin-RevId: 538230923

Fixes #12944 PiperOrigin-RevId: 537907016

Cherry-pick portability fixes to 23.x line

Protobuf is likely not in scope for the fixed CVE, but updating out of an abundance of caution.

PiperOrigin-RevId: 539109983

- 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

PiperOrigin-RevId: 538812352

See actions/runner-images#7662 PiperOrigin-RevId: 537946689

Backport GHA cleanup

* Updated upb dep to the latest 23.x commit. * Updated upb dep to the latest 23.x commit.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Comparing changes

Open a pull request

Commits on May 25, 2023

Commits on Jun 5, 2023

Commits on Jun 6, 2023

Commits on Jun 7, 2023

Commits on Jun 8, 2023

Commits on Jun 9, 2023

Commits on Jun 13, 2023

Commits on Jun 14, 2023

This comparison is taking too long to generate.

Uh oh!