2

Opensuse tumbleweed comes with glibc2.29, and so everything else in the system is dependant on it.

However, I have CrashPlanDesktop and it needs 2.27 max.

I found an opensuse repo with 2.27 easily.

However, trying to install it results in this:

rpm: /lib64/libc.so.6: version `GLIBC_2.27' not found (required by /usr/lib64/libpopt.so.0)

How can I solve this?

The CrashPlanDesktop has to communicate to a service.

Can I use chroot or something else?

Can I extract the rpm into the folder with the executable?

Additionally I got this message, but don't know what it means

Code: d6 21 12 e3 c4 a7 81 1d 7a 48 5f 26 5f 37 b8 f1 ed f5 f8 7c 86 e8 25 4c a5 5a 29 b7 45 41 0c cc a7 76 95 b4 93 d9 d8 5e 4c b8 f4 95 11 c4 9f 2c fc 6d a0 1d 3c 50 4a e0 5a 6b 48 18 f7 b9 ab

  • The glibc folks are generally really, really careful to maintain backwards compatibility. Does CrashPlanDesktop give any indication which it has this requirement? – Philip Kendall Mar 1 at 7:16
  • @PhilipKendall From support "There is a known incompatibility with glibc 2.28 that prevents the CrashPlan UI from opening." At this time there is no workaround available This is all I could get from them. crashplan[8344]: segfault at c39ea0 ip 0000000000c39ea0 sp 00007ffcabb41868 error 15 in crashplan[200000+1603000] – cybernard Mar 1 at 13:34
  • Ah ha, I suspect it's related to this Electron issue. Sounds like it's a regression in some builds of glibc 2.28 and should work fine with glibc 2.29. – Philip Kendall Mar 1 at 13:43
  • @PhilipKendall Sounds like a great theory except I have glibc-2.29-2.1 installed. – cybernard Mar 1 at 14:25
0

I was actually able to work-around this downloading Electron 2.0.8, extracting libnode.so from the archive, and replacing /usr/local/crashplan/electron/libnode.so with the one from the electron 2.0.8 zip.

My system is Debian, but I imagine that this might also work for OpenSuse.

(This is of course unofficial, unsupported by Code42, or anyone else)

New contributor
AMeiri is a new contributor to this site. Take care in asking for clarification, commenting, and answering. Check out our Code of Conduct.
0

The glibc is backwards compatible, so code built to work on glibc 2.27 should keep working on glibc 2.29.

To implement backwards compatibility, glibc uses symbol versioning to mark when a function was introduced. If a function ever changes behavior (specially when it changes prototype) a new symbol version will be introduced for that version. But code built with the older glibc (which depends on the older behavior) will still bind to the older symbol version with the older behavior.

Most Linux distributions don't really support installing multiple glibc versions in parallel, since they would have to be installed in paths that include the full version (the name of the library itself, called "SONAME", is the same for all glibc versions, so can't be used by itself to differentiate them.) But then there's a problem with deciding which one to use for which binary. So then you need separate loaders (dynamic linkers) for each library version, but then you need to set the interpreter when you build binaries for each version (or patch the interpreter on existing binaries.) In short, it's possible to install multiple versions of glibc, but it's a complex setup and it's really painful to use.

If your application really needs glibc 2.27 and doesn't work with glibc 2.29 (but, as mentioned above, this should work, so that would be a bug in glibc 2.29), then your best bet is to run it on a Linux distribution that ships glibc 2.27 by default.

If changing the Linux distribution of your host is not an option, then consider running your application in a container, and build the container image from a distribution with the appropriate version of glibc.

  • 1
    I'm suspecting it's related to this issue in some builds(?) of glibc 2.28. – Philip Kendall Mar 1 at 13:43
  • I was thinking about a container of some kind, but what can I use? It needs to display a GUI, and communicate with the service on the local host. I was thinking maybe docker by I don't think that supports a GUI. Is there another way to sandbox it? A full virtual machine is 100% isolated so there it can't communicate with the local service. – cybernard Mar 1 at 16:01
  • could I somehow use chroot and make a directory x and install all related libraries and components in there? – cybernard Mar 1 at 16:35
  • It is possible to use Docker containers for an application with GUI, but it's tricky to do it since you need to forward/mount the X11 socket and also forward X11 authentication to it... The same is also the case with chroot (or something like systemd-nspawn.) There are also "application virtualization" systems, which solve large part of that problem since they're made for GUI. Look at Flatpak or SnapCore (the latter comes from Canonical, makers of Ubuntu.) Snaps are built with this tool snappy that makes it fairly easy to wrap an application in a container. – filbranden Mar 1 at 23:48
  • This is really a topic for a separate question... You should ask about that in another question, since there will be others who have more experience in all of the above (running GUI in Docker, or packaging them in Flatpak/SnapCore) and will be able to give better answers. – filbranden Mar 1 at 23:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.