Need to install glibc >= 2.14 on Wheezy

  • 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/ 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/ 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

    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.

    I added the terminal output above showing where 2.14 or 2.15 was required. However all is working now.

  • Braiam

    Braiam Correct answer

    7 years ago

    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


    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.

    That did it. Following the debian instructions at 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.

    Thanks, but perhaps you should also set-up apt-pinning as explained in

    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`

    @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 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...

    @SeanDeNigris Actually, just wait for a while. Jessie (current testing) is about to be released.

    That's good news! But, we're releasing Monday so I have to come up with the least-bad answer for the immediate future :/

    This accepted solution really should have a warning. I followed it and ended up with 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.

    @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*. 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.

    @Stacey "My current **development** box is running Debian Wheezy"????

    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***?""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.

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM