pointers please! /lib/libc.so.6: version `GLIBC_2.14' not found (required by...)

[hexa...@gmail.com]

Hello,

First, thanks for such a beautiful language. I'm really enjoying go.

I'm having a wee problem.

I build a go program on ubuntu 13.10 (go1.1.2). All lovely.

I upload it to my web host, and run into:

./tick: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./tick)

There's no go on the web host (nor likely to be). Here's what it reports for glibc 

/lib/libc.so.6

GNU C Library (Debian EGLIBC 2.11.3-4) stable release version 2.11.3, by Roland McGrath et al.

I'm guessing there's a little bit of magic I could add to the build to bind to an older glibc, or somehow get the binary on the server to talk to a local copy of glibc which is more recent, but this is a little beyond me: I left the golden lands of occam and c++ 20 years ago, and python etc. fell away about 10 years ago, so I'm rustier than a battleship chain in the salty abyss past "yank data out of databases and beat it until it confesses."

Your help much appreciated,

Vinay Gupta

Hexayurt Project

http://hexayurt.com

PS: I'll probably be back when it's time to talk about mod_proxy too, but that's tomorrow's issue!

[Caleb Spare]

There are probably better solutions, but what I've done in the past is use an older linux for compiling when I deploy (e.g. on Jenkins, or on a virtual machine or Docker container on my own box).

[Jan Mercl]

On Fri, Dec 13, 2013 at 4:34 PM, <hexa...@gmail.com> wrote:
> ./tick: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./tick)

Not in the general case, but some programs can get rid of that .so
dependency when built like

$ CGO_ENABLED=0 go build

-j

[minux]

On Fri, Dec 13, 2013 at 10:34 AM, <hexa...@gmail.com> wrote:

Hello,

First, thanks for such a beautiful language. I'm really enjoying go.

I'm having a wee problem.

I build a go program on ubuntu 13.10 (go1.1.2). All lovely.

I upload it to my web host, and run into:

./tick: /lib/libc.so.6: version `GLIBC_2.14' not found (required by ./tick)

this is one of the major failure of introducing symbol versioning into dynamic libraries.

only of the most often quoted benefit of using shared library is gone. (shared libraries

are supposed to reduce duplication, with symbol versioning they're introducing more

and problems like this!)

There's no go on the web host (nor likely to be). Here's what it reports for glibc 

/lib/libc.so.6

GNU C Library (Debian EGLIBC 2.11.3-4) stable release version 2.11.3, by Roland McGrath et al.

I'm guessing there's a little bit of magic I could add to the build to bind to an older glibc, or somehow get the binary on the server to talk to a local copy of glibc which is more recent, but this is a little beyond me: I left the golden lands of occam and c++ 20 years ago, and python etc. fell away about 10 years ago, so I'm rustier than a battleship chain in the salty abyss past "yank data out of databases and beat it until it confesses."

unfortunately, no magic here.

you have several alternatives:

1. if your program doesn't use cgo (either directly or indirectly, exclude those in the standard library), you can

try build it with the binary distributions which is compiled with an old enough glibc.

2. you can disable cgo, and rebuild go (set CGO_ENABLED=0, then run src/make.bash)

3. alternatively to 3, if the only reason cgo is used is the net package, you can try build the net package with the

"netgo" build tag. go build -a -v -tags netgo std; and then rebuild your program.

4. use a chroot with an environment that matches the production server, and build Go and your program in that chroot.