Chiebot-Mirror/protobuf - protobuf - Gitea: Git with a cup of tea

Author	SHA1	Message	Date
Eric Salo	2256f918af	upb: use upb_Message_IsEqual() in Ruby PiperOrigin-RevId: 622913519	8 months ago
Joshua Haberman	ba9e2afcfc	Shorten our license headers into an abbreviated form that references LICENSE instead of including it in full. PiperOrigin-RevId: 563889003	1 year ago
Jason Lunn	c52d80cf04	Ruby FFI implementation (#13343 ) Supersedes #11483. Closes #13343 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13343 from protocolbuffers:simultaneous_ffi `bcb4bb7842` PiperOrigin-RevId: 550782245	1 year ago
مهدي شينون (Mehdi Chinoune)	c2f07bb80f	Fix building shared libraries on MinGW-w64 (#13240 ) Closes #13240 COPYBARA_INTEGRATE_REVIEW=https://github.com/protocolbuffers/protobuf/pull/13240 from MehdiChinoune:mingw-shared `45600c9ccc` PiperOrigin-RevId: 546541196	1 year ago
Romain Geissler @ Amadeus	4329fde9cf	Use the same ABI for static and shared libraries on non-Windows platforms (#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 `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	2 years ago
Protobuf Team Bot	d41deb9dc6	Internal change that helps identify the origin of reflection calls. PiperOrigin-RevId: 510255963	2 years ago