* Remove protoc release for 32-bit Macs
Apple has been removing the support for 32-bit Mac apps: https://support.apple.com/en-us/HT208436
Our release infrastructure no longer supports building for 32-bit architecture.
* Remove protoc artifact for MacOS 32-bit
* Add changelog for 3.9.x
* Revert "Make php message class final to avoid mocking (#6277)" (#6324)
This reverts commit 7f84a94366.
This is just temporary. Eventually, we still want to roll forward this
change. Some users are complaining they need more time to clean up their
code.
* Update extract_includes.bat.in
File io_win32.h is not in directory google\protobuf\stubs under directory google\protobuf\io
* Set oneof case in array constructor (#6351)
Forgot to set it previously.
* Update protobuf version (#6366)
* Drop building wheel for python 3.4 (#6406)
https://github.com/matthew-brett/multibuild/pull/240
* Fix binary compatibility in FieldCodec factory methods (#6380) (#6424)
* Fix binary compatibility in FieldCodec factory messages
* Make default value parameter for current factories required
* Route old methods through default value overloads
* Remove ExtensionRegistry.Add(params) overload
* Rename ExtensionRegistry.Add(IEnumerable<Extension>) overload to AddRange
* Edit naming of parameters in Extension classes
* * Fix add API warnings to docs for extension APIs
* Rename internal ExtensionSet.GetValue to TryGetValue
* Disable javadoc error (#6371)
* Disable javadoc error
Actual fixes of the javadoc will be followed up
* Remove duplicated configuration
* Update javadoc plugin version
* Updated Bazel test script to use most recent Bazel version (#6413) (#6433)
I'm not exactly sure why, but this fixes the failing Bazel presubmit
test. Using the most recent version seems like a good idea anyway so
that we can make sure we're compatible with any new Bazel changes.
* [bazel] Add fixes for --incompatible_load_{cc,java,proto}_rules_from_bzl
* No need to update version in generated code (#6471)
generate_descriptor will handle that
* Update protobuf version (#6472)
We ran into problems with precompiled protoc binaries not working on
some systems because of the dependence on a dynamically linked
libatomic. However, I found that linking against libatomic is not
actually necessary in our protoc build environment. Inside configure.ac
there's a test which figures out if we need to pass -latomic, and it
does this by attempting to build a test binary. That binary was failing
to build, but it turns out this was because we need to pass -std=c++11,
not -latomic.
This fixes#5875.
This was fairly straightforward using the existing build-protoc.sh
script. The only problem I ran into was that the x86 Docker builds
create output directories owned by root, which caused some permission
issues. Fortunately it was easy to get around that just by doing those
Docker builds last.
I made a few small fixes to the documentation related to publishing
protoc artifacts:
- The target directory for Mac should be called osx instead of macos.
- There needs to be a directory for aarch_64.
- We need to avoid calling "mvn clean" inside the protoc-artifacts
directory, since that will delete the contents of the target/
subdirectory.
This avoids the need to use "yum update && yum upgrade" in the container
to be able to contact GitHub, which requires TLS 1.2[1].
I have verified that binaries built with this container still run in the
previous container; no errors like "/lib64/libc.so.6: version
`GLIBC_2.14' not found", which occur if using too new of a glibc when
compiling. CentOS 6.6 has glibc version 2.12 release 1.209.el6. CentOS
6.9 has glibc version 2.12 release 1.149.el6. Both would upgrade to
release 1.212.el6 via "yum update && yum upgrade".
1. https://githubengineering.com/crypto-deprecation-notice/
Joshua Haberman
listonjesse
Rafi Kamal
salamaniibm
Jie Luo
Hao Nguyen
Paul Yang
Adam Cozzette
Bo Yang
Hao Nguyen
Feng Xiao
Adam Cozzette
Eric Anderson