Repository: borgbackup/borg

Issue:
glibc compatibility documentation
I just noticed 0.29.0 was released and in the notes it indicates that a ticket should be opened if you need a CentOS 6 build, which I do. Also, thank you for Borg, the mix of features and performance make it the best backup system I've used.



Discussion:
Hi! So you work on centos6 where the normal binary does not work?

Anyone else with older linux dist?

I think this can be closed, I assumed since there was a CentOS 6 specific build for 0.28.2, that there needed to be a CentOS 6 build for 0.29.0 after seeing the note in the readme file. Anyhow, the generic build does seem okay for me on CentOS 6, thank you.

Ehrm, that the generic build works on centos6 is rather unexpected.
Can you tell your (g)libc version on centos6?

$ borg -V
borg 0.29.0

$ rpm -q glibc
glibc-2.12-1.166.el6_7.3.i686

Just tested it again, and it completed without error.
Start time: Tue Dec 15 19:10:42 2015
End time: Tue Dec 15 19:12:29 2015
Duration: 1 minutes 47.43 seconds
Number of files: 310364

Debian 7 "wheezy" has 2.13-38.

So, if that binary works for you on centos6, the glibc version check seems to be not just ">=" (as I believed). That's good. 2 binaries less to build. \o/

Question: is there some documentation about glibc and how to find out what's compatible and what not?

glibc uses elf symbol versioning.

if you run objdump -T on all code you get a version for every symbol used.

```
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 memcpy
```

in principle these version tags could be anything and a binary is compatible to a libc that has all the version strings that your executable has. In practice the gnu libs uses release version numbers a version strings so you would only need to look for the most recent version. Different symbols can have different "most recent" versions, so if a program doesn‘t use some symbols it could easily be compatible with libc versions quite a bit older than the version used to compile the code.

Just tried for the borg-linux64 1.0.3 binary: most symbols are glibc 2.2.5 and one is glibc 2.3 (realpath).

I did the build on debian7 with glibc 2.13. So it seems the pyinstaller bootloader can cope with a quite older glibc.

Now looking at what's inside:

```
2.13 prlimit64 from: resource.cpython-35m-x86_64-linux-gnu.so
2.11 __longjmp_chk from: libreadline.so.6
2.10 accept4 from: _socket.cpython-35m-x86_64-linux-gnu.so
2.9 dup3, pipe2 from: libpython3.5m.so.1.0
2.9 epoll_create1 from: select.cpython-35m-x86_64-linux-gnu.so
```

So, 2.10, 2.11, 2.13 requirement seems to come from some python stdlib modules (their C parts).

Does that mean that as long as these modules are not used (imported by some python code), it would work without their glibc requirement (== on a older glibc)?

So, if we do not use "resource" implies we can live with less than 2.13?

Note: resource.getpagesize() is used by platform/linux.pyx (in master / 1.1dev, not in 1.0-maint) since recently.

I think the best way would be to build with a python that was build with an older libc.

But .so files that are not loaded should not influence the needed libc on the target system. So avoiding to use these modules would be a possible way to reduce libc dependencies.

one way to see which libraries are loaded is to use pmap -p <pid> on a running process and look at the maped .so files.

> Note: resource.getpagesize() is used by platform/linux.pyx since recently.

If that's the only issue then that can be trivially replaced in the cython code with sysconf(3)

Strangely enough, borg binary 1.0.3 works on centos6 (32bit) - init, create, list, extract didn't show problems.

https://github.com/borgbackup/borg/pull/1270 adding a glibc compat checker script there.

It only determines what the given binaries "want", not if the binaries are really used (like some dynamically linked library - it could be used or not).


Resolving patch:
diff --git a/scripts/glibc_check.py b/scripts/glibc_check.py
old mode 100644
new mode 100755
--- a/scripts/glibc_check.py
+++ b/scripts/glibc_check.py
@@ -2,7 +2,9 @@
 """
 Check if all given binaries work with the given glibc version.
 
-check_glibc.py 2.11 bin [bin ...]
+glibc_check.py 2.11 bin [bin ...]
+
+rc = 0 means "yes", rc = 1 means "no".
 """
 
 import re


Test patch: