Ruby: wrap calls to memcpy so that gem is compatible with pre-2.14 glibc#2804
Merged
acozzette merged 1 commit intoprotocolbuffers:masterfrom Mar 9, 2017
Merged
Ruby: wrap calls to memcpy so that gem is compatible with pre-2.14 glibc#2804acozzette merged 1 commit intoprotocolbuffers:masterfrom
acozzette merged 1 commit intoprotocolbuffers:masterfrom
Conversation
Author
|
@haberman @nicolasnoble Does this look ok? |
Contributor
|
The point of the memmove call is to provide an alternative to the "x86_64" case; if someone builds that code on linux that isn't Intel 64 bits, the resolution of the _wrap_memcpy symbol won't happen and you'll get a linker error. |
Contributor
|
Also, you should only add the LDFLAGS if the OS is Linux. |
Author
|
Thanks @nicolasnoble, I went ahead and made those fixes. I was thinking I would actually prefer to use |
This commit adds a __wrap_memcpy function and a linker flag to use that in place of memcpy for our Ruby gem C extension. This allows us to always use the 2.2.5 version of memcpy, making it possible to use the gem on distributions with pre-2.14 versions of glibc. Before this change: $ objdump -T protobuf_c.so | grep memcpy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4 __memcpy_chk 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.14 memcpy After: $ objdump -T protobuf_c.so | grep memcpy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.2.5 memcpy 0000000000000000 DF *UND* 0000000000000000 GLIBC_2.3.4 __memcpy_chk 0000000000042450 g DF .text 0000000000000005 Base __wrap_memcpy This is based on gRPC's solution to a similar problem: https://github.com/grpc/grpc/blob/5098508d2d41a116113f7e333c516cd9ef34a943/src/core/lib/support/wrap_memcpy.c This fixes issue protocolbuffers#2783.
Member
|
LGTM. |
copybara-service Bot
pushed a commit
that referenced
this pull request
Jun 26, 2025
This shim was added in 2017 to make binary gems compatible with pre-2.14 glibc: #2804 glibc 2.14 was released in 2011. Our Python wheels build for manylinux 2014, which requires glibc 2.17 or later: https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux2014-centos-7-based-glibc-217 We should no longer need binary compatibility with a 14-year-old glibc. Fixes: #11935 PiperOrigin-RevId: 776175307
copybara-service Bot
pushed a commit
that referenced
this pull request
Jun 26, 2025
This shim was added in 2017 to make binary gems compatible with pre-2.14 glibc: #2804 glibc 2.14 was released in 2011. Our Python wheels build for manylinux 2014, which requires glibc 2.17 or later: https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux2014-centos-7-based-glibc-217 We should no longer need binary compatibility with a 14-year-old glibc. Fixes: #11935 PiperOrigin-RevId: 776175307
copybara-service Bot
pushed a commit
that referenced
this pull request
Jun 26, 2025
This shim was added in 2017 to make binary gems compatible with pre-2.14 glibc: #2804 glibc 2.14 was released in 2011. Our Python wheels build for manylinux 2014, which requires glibc 2.17 or later: https://github.com/pypa/manylinux?tab=readme-ov-file#manylinux2014-centos-7-based-glibc-217 We should no longer need binary compatibility with a 14-year-old glibc. Fixes: #11935 PiperOrigin-RevId: 776288819
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This commit adds a __wrap_memcpy function and a linker flag to use that
in place of memcpy for our Ruby gem C extension. This allows us to
always use the 2.2.5 version of memcpy, making it possible to use the
gem on distributions with pre-2.14 versions of glibc.
Before this change:
$ objdump -T protobuf_c.so | grep memcpy
0000000000000000 DF UND 0000000000000000 GLIBC_2.3.4 __memcpy_chk
0000000000000000 DF UND 0000000000000000 GLIBC_2.14 memcpy
After:
$ objdump -T protobuf_c.so | grep memcpy
0000000000000000 DF UND 0000000000000000 GLIBC_2.2.5 memcpy
0000000000000000 DF UND 0000000000000000 GLIBC_2.3.4 __memcpy_chk
0000000000042450 g DF .text 0000000000000005 Base __wrap_memcpy
This is based on gRPC's solution to a similar problem:
https://github.com/grpc/grpc/blob/5098508d2d41a116113f7e333c516cd9ef34a943/src/core/lib/support/wrap_memcpy.c
However, we have not so far run into any issues with callers using
memcpy when they should be using memmove, so in this commit I did not
add anything to redirect memcpy to memmove.
This fixes issue #2783.