23

I am trying to get Protractor working for performing e2e angular testing, but protractor requires Selenium which requires ChromeDriver which requires glibc 2.14. My current development box is running Debian Wheezy which comes with glibc 2.13. I have read that switching over to Debian's unstable branch would provide access to glib-2.14, but from what I have heard unstable is pretty...unstable.

Is there any way I can upgrade glibc to 2.14 or 2.15 without the risk of breaking everything? Or is it possible to switch back from the unstable Debian branch if things start to break?

12:15:22.784 INFO - Executing: [new session: {browserName=chrome}] at URL: /session)
12:15:22.796 INFO - Creating a new session for Capabilities [{browserName=chrome}]
/home/chris/projects/personal/woddy/client/selenium/chromedriver:     /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.15' not found (required by      /home/chris/projects/personal/woddy/client/selenium/chromedriver)
/home/chris/projects/personal/woddy/client/selenium/chromedriver: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by /home/chris/projects/personal/woddy/client/selenium/chromedriver)
12:15:43.032 WARN - Exception thrown
java.util.concurrent.ExecutionException: org.openqa.selenium.WebDriverException:  java.lang.reflect.InvocationTargetException
Braiam
  • 35,991
chris
  • 503
  • Where does it say that ChromeDriver requires glibc 2.14? In general, high level packages don't have very narrow constraints on the C library. Does it say so somewhere in the documentation or the code, or is it simply listed as a dependency in some package? Be aware, if you are not already, that distribution packages may add overly strict dependencies for no good reason. – Faheem Mitha Aug 05 '13 at 08:35
  • I added the terminal output above showing where 2.14 or 2.15 was required. However all is working now. – chris Aug 05 '13 at 18:41

3 Answers3

24

You don't have to switch to the unstable to get glib >= 2.14. In fact, the testing branch (now stable, or Jessie) has glib-2.17 which you can pick just adding the testing repository and launching:

sudo apt-get install libc6-dev=2.17-7

or,

sudo apt-get -t testing install libc6-dev

You can add the switch --dry-run to see what will being installed before hand. You can see the status of the glibc package in the Debian Package Tracker System (Debian renamed eglibc package to simply glibc from Jessie onwards).

You can also just wait for Jessie release on April 25.

Braiam
  • 35,991
  • 2
    That did it. Following the debian instructions at http://www.debian.org/doc/manuals/apt-howto/ch-apt-get.en.html#s-default-version then running the second command you listed worked perfectly. Thanks for the help. BTW I had it in my head that unstable was the next step up instead of testing. – chris Aug 05 '13 at 18:35
  • Thanks, but perhaps you should also set-up apt-pinning as explained in http://verahill.blogspot.ie/2014/03/562-pulling-in-glibc-214-from-testing.html – gatopeich Jul 10 '14 at 08:37
  • 2
    Neither of these worked for me. The first method produced E: The value 'testing' is invalid for APT::Default-Release as such a release is not available in the sources and the second E: Version '2.17-7' for 'libc6-dev' was not found – Sean DeNigris Apr 11 '15 at 14:01
  • @SeanDeNigris "the testing branch has glib-2.17 which you can pick just adding the testing repository" you need to add the testing repositories to your sources.list and update the package lists. – Braiam Apr 11 '15 at 14:16
  • @Braiam Thanks. I was interested in your approach because I'm updating the installation instructions for Pharo. I liked it specifically because it didn't involve hacking config files, since we attract some non-programmer types. I guess maybe I could pin libc-only to testing... – Sean DeNigris Apr 11 '15 at 18:28
  • @SeanDeNigris Actually, just wait for a while. Jessie (current testing) is about to be released. – Braiam Apr 11 '15 at 18:34
  • That's good news! But, we're releasing Monday so I have to come up with the least-bad answer for the immediate future :/ – Sean DeNigris Apr 12 '15 at 02:55
  • 1
    This accepted solution really should have a warning. I followed it and ended up with a "FrankenDebian": https://wiki.debian.org/DontBreakDebian#Don.27t_make_a_FrankenDebian

    I then spent the next 2-3 hours fighting my way out of dependency hell and getting my system back to a stable Wheezy.

     – stanri Apr 23 '15 at 05:43
  • @Stacey "You can add the switch --dry-run to see what will being installed before hand." There was a method to verify what would happen before hand, you just need to test it. Also, it's presumed you know what you are doing and have a good reason to do it. – Braiam Apr 23 '15 at 12:45
  • 1
    Debian.org explicitly mentions that this is a bad idea. Not everyone is a sysadmin. The OP asked for a safe , recommended solution, that does not break anythong, and this solution does not meet any of those criteria. – stanri Apr 23 '15 at 17:12
  • @Stacey "My current development box is running Debian Wheezy"???? – Braiam Apr 23 '15 at 17:18
  • 2
    Since we're quoting things now. OP: "Is there any way I can upgrade glibc to 2.14 or 2.15 *without the risk of breaking everything?" Debian.org:"it's not a good idea to add repositories for other Debian releases.... This results in a system that is a broken mix of the two.*" How much more clear can I be? Hopefully people will read the comments before the taking this advice. I'm done. – stanri Apr 23 '15 at 18:19
23

In my situation, the error appears when I try to run an application (compiled on Ubuntu 12.04 LTS) using GLIBC_2.14 on Debian Wheezy (which installs glibc 2.13 by default).

I use a tricky way to run it, and get correct result:

  1. Download libc6 and libc6-dev from Ubuntu 12.04 LTS

  2. Run dpkg command to install them into a directory (/home/user/fakeroot/ for example): 

    $ dpkg -x libc6-dev_2.15-0ubuntu10.6_amd64.deb /home/user/fakeroot/
$ dpkg -x libc6_2.15-0ubuntu10.6_amd64.deb /home/user/fakeroot/

  3. Run your command with specified LD_LIBRARY_PATH:

    $ LD_LIBRARY_PATH=/home/user/fakeroot/lib/x86_64-linux-gnu/ YOUR_COMMAND

  4. My application only uses memcpy() from GLIBC_2.14, and it works.

    I don't know whether it will work successfully for other applications.

tshepang
  • 65,642
Bin S
  • 371
  • Thanks! These instructions allowed me to easily run Shaka Packager on Debian Wheezy. I'm wrapping my command in a bash script that looks like exec env LD_LIBRARY_PATH=/home/user/fakeroot/lib/x86_64-linux-gnu/ YOUR_COMMAND "$@" so that the command is easily available without needing to specify LD_LIBRARY_PATH every time. – Gabe Kopley Jul 06 '16 at 19:08
  • libc6 links are broken – simo Sep 13 '20 at 11:14
1

I guess there are several options for you to try out the unstable branch "safely":

  • Virtualization
  • Chrooting whereby you choose an alternative directory as your apparent root directory. You can thus create a file system image and manually install the required packages. This is a complicated process and it is made much easier in Debian's case using:

  • deboostrap which, to quote the Debian Wiki article at this link, is

    a tool which will install a Debian base system into a subdirectory of another, already installed system. It doesn't require an installation CD, just access to a Debian repository.

    This is not to imply that debootstrap uses the chrooting technique; I'm not aware of its internal implementation.

Joseph R.
  • 39,549
  • I used the debootstrap tutorial and it was just what I needed:https://wiki.debian.org/Debootstrap

    I followed the sid example but used jessie instead: debootstrap --arch amd64 jessie $MY_CHROOT http://http.debian.net/debian/

    Thank you!

     – Drew LeSueur Apr 24 '15 at 14:32