Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

protoc plugin doesn't work on RHEL 6 #45

Open
neilswingler opened this issue Sep 18, 2019 · 2 comments
Open

protoc plugin doesn't work on RHEL 6 #45

neilswingler opened this issue Sep 18, 2019 · 2 comments
Labels
bug Something isn't working

Comments

@neilswingler
Copy link

Unfortunately RHEL 6 (6.10) is still mainstream at work and the protoc plugin fails with this error:

ERROR] PROTOC FAILED: xxxxxx/target/protoc-plugins/rsocket-rpc-protobuf-0.2.19-linux-x86_64.exe: /lib64/libc.so.6: version 'GLIBC_2.14' not found (required by xxxxxx/target/protoc-plugins/rsocket-rpc-protobuf-0.2.19-linux-x86_64.exe)

--rsocketRpc_out: protoc-gen-rsocketRpc: Plugin failed with status code 1.

Protoc itself works fine.

@robertroeser robertroeser added the bug Something isn't working label Oct 6, 2019
@robertroeser
Copy link
Member

@flyinprogrammer you think you can help with this?

@flyinprogrammer
Copy link
Contributor

flyinprogrammer commented Oct 7, 2019

TL;DR: Based on my assumptions, I believe the fastest, short-term solution we have for you is to download this source code, checkout the tagged version of the plugin you prefer, compile it on your RHEL system, and then publish it within your own ecosystem as the package to use for yourself and anyone that needs supporting.

While you're doing that, I'll see what we'll have to do to get the build to run in a CentOS 6 container.


As the TL:DR might suggest, I suspect this is going to be a bit more challenging to support than we'd all like.

I suspect that this error is telling us that rsocket-rpc-protobuf-0.2.19-linux-x86_64.exe has been compiled against GLIBC 2.14 - which is newer, and incompatible with the GLIBC 2.12 version running on your system, and to get past this error we'll need to compile the plugin with GLIBC 2.12 or older.

To provide evidence of this being the error, you can verify your GLIBC version this by running ldd --version on your system:

$ ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Given that assumption, we might have 2 choices, tell gcc to compile to/against a backward compatible, older version of GLIBC - or get us a build environment running an older version of GLIBC.

At the time of writing, I'm unaware of how to get gcc to target any other version of glibc than what is available in the build environment, and historically I've found the fastest, easiest, and most reliable way to change what version of glibc should be targeted is to use an OS who's versions align with our goal.

This means finding a distro that still relies on GLIBC 2.12 or older.

Today, we use Travis CI to build and publish our artifacts. The only linux distro Travis CI supports is Ubuntu, and the oldest release they support is Precise 12.04.5 LTS.

I made a little project to figure out what versions of glibc they're building with:

Precise: https://travis-ci.org/flyinprogrammer/thequestforglibc/builds/594670279

0.01s$ ldd --version
ldd (Ubuntu EGLIBC 2.15-0ubuntu10.18) 2.15
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
The command "ldd --version" exited with 0.

Trusty: https://travis-ci.org/flyinprogrammer/thequestforglibc/builds/594671057

0.00s$ ldd --version
ldd (Ubuntu EGLIBC 2.19-0ubuntu6.13) 2.19
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
The command "ldd --version" exited with 0.

Xenial: https://travis-ci.org/flyinprogrammer/thequestforglibc/builds/594671321

0.01s$ ldd --version
ldd (Ubuntu GLIBC 2.23-0ubuntu11) 2.23
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
The command "ldd --version" exited with 0.

Bionic: https://travis-ci.org/flyinprogrammer/thequestforglibc/builds/594671567

0.01s$ ldd --version
ldd (Ubuntu GLIBC 2.27-3ubuntu1) 2.27
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
The command "ldd --version" exited with 0.

And none of them are viable options, which is a bummer.

So since this isn't going to be a small YAML change, I started looking into what our options might be if we ran the builds inside linux containers, and it looks like the Centos 6 container will satisfy our issue, providing we don't run into other issues of course:

$ docker run --rm centos:6 ldd --version
ldd (GNU libc) 2.12
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants