protoc plugin doesn't work on RHEL 6 #45

Activity

1. robertroeser

   added

   bugSomething isn't workingSomething isn't working

   on Oct 6, 2019
2. robertroeser commented on Oct 6, 2019

   

   robertroeser

   on Oct 6, 2019

   Member

   More actions

   @flyinprogrammer you think you can help with this?
3. flyinprogrammer commented on Oct 7, 2019

   

   flyinprogrammer

   on Oct 7, 2019

   Last edited by flyinprogrammer

   Contributor

   More actions

   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.