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/
Now that we depend on C++11, we need at least GCC 4.8 instead of 4.7.
This change updates the Docker setup to continue using CentOS 6.6 but
with GCC 4.8.
I also added libm to the whitelist for dynamically linked libraries for
the ARM64 protoc binary.
1. Changed maven script to only do artifact uploading and removed build
script invocation from it. We didn't use maven to invoke the build
script before (we built protoc manually and editted pom.xml to only do
uploading for previous releases), and will not use it in the future (we
will use kokoro to build artifacts).
2. Cleaned up build-protoc.sh and README.md: removed the part about
using maven to build and listed supported platforms explicitly.
1. Changed maven script to only do artifact uploading and removed build
script invocation from it. We didn't use maven to invoke the build
script before (we built protoc manually and editted pom.xml to only do
uploading for previous releases), and will not use it in the future (we
will use kokoro to build artifacts).
2. Cleaned up build-protoc.sh and README.md: removed the part about
using maven to build and listed supported platforms explicitly.
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/
Now that we depend on C++11, we need at least GCC 4.8 instead of 4.7.
This change updates the Docker setup to continue using CentOS 6.6 but
with GCC 4.8.
I also added libm to the whitelist for dynamically linked libraries for
the ARM64 protoc binary.
ENTRYPOINT is used even when other commands are specified on the "docker
run" command line. This allows running one-off commands in the docker
image (especially combined with volume binding with the host) with the
correct environment variables.
It is a bad idea to check out code into the docker image, as it will be
out-of-date. It is better to have the image just be the environment, and
let any scripts that need source check them out themselves.
This fixes#4419 in that it allows the image to build again, albeit
users would need to use wget to grab the source of the version of
protobuf they wish.
Ran into an issue today where a machine had the `protoc` compiler but not the include files. Took a while to sort out, and this added note to the README included in every zip should help.
Paul Yang
Adam Cozzette
Bo Yang
Hao Nguyen
Hao Nguyen
Feng Xiao
Adam Cozzette
Eric Anderson
nashimus
Jisi Liu
pravin-dsilva
Bo Yang
Jisi Liu
Daniel Taylor
Łukasz Strzałkowski