1

I am trying to deploy a c++ application with log4cxx.so and is requiring glibc 2.14, but the machine being deploy has 2.12 glibc. Is is necessary to upgrade this machine to glibc 2.14 in order to run this application? Or there is other more portable way?

Bryan Fok
  • 3,277
  • 2
  • 31
  • 59
  • 1
    You could try statically linking the library. Google should turn up the "how to" info. – Tony Delroy Apr 22 '13 at 09:22
  • this might help: [How compatible are different versions of glibc?][1] [1]: http://stackoverflow.com/questions/11107263/how-compatible-are-different-versions-of-glibc – andrjas Apr 22 '13 at 09:26
  • 1
    Then, if it's too hard to deploy a new version of glibc, statically link your executable. – phoeagon Apr 22 '13 at 10:35
  • I am trying to statically link log4cxx. I got the log4cxx.a, but i dont have the static lib for the apr, and apr-util (log4cxx dependency), i only have their .so. do you guys know how to statically link log4cxx? – Bryan Fok Apr 22 '13 at 10:40
  • @phoeagon: It is **ILLEGAL** to link glibc to a **closed-source** program statically (license requires LGPL on all statically linked code). – Jan Hudec Apr 22 '13 at 11:50

1 Answers1

2

Linux binary portability is a pain. Linux uses symbol versioning, so you should be able to find out what symbols are needed with:

nm binary | grep @@GLIBC_ | sort -t@ -k14

You may be able to inline the functions and remove the dependency on newer glibc.

You can read more here. Generally the best option for portability is to compile against an older version of glibc or just to provide sources and a MAKEFILE.

Glitch Desire
  • 14,632
  • 7
  • 43
  • 55