User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 Build ID: 20150922203042 Steps to reproduce: Downloaded wires-0.4.2-linux64.tar.gz from https://developer.mozilla.org/en-US/docs/Mozilla/QA/Marionette/WebDriver on a CentOS 6.6 VM (CentOS 6 is a requirement of the local work environment) unpacked it, tried to start it: $ chmod +x wires-0.4.2-linux64 $ ./wires-0.4.2-linux64 Actual results: ./wires-0.4.2-linux64: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./wires-0.4.2-linux64) ./wires-0.4.2-linux64: /lib64/libc.so.6: version `GLIBC_2.18' not found (required by ./wires-0.4.2-linux64) $ ls -l /lib64/libc.so.6 lrwxrwxrwx. 1 root root 12 Sep 24 15:17 /lib64/libc.so.6 -> libc-2.12.so Expected results: wires should have started after unpacking the linux64 tar gz file I finally managed to find the link to the source archive, install rust, build it from source and copy it to the path, but selenium python webdriver 2.48.0 is still not working. webdriver.firefox.service.py:64 expects a path and gets a FirefoxBinary instead. Having corrected that by referencing firefox_binary._start_cmd, I get the following error: Traceback (most recent call last): [...] File ".../selenium/webdriver/firefox/webdriver.py", line 65, in __init__ keep_alive=True) File ".../selenium/webdriver/remote/webdriver.py", line 87, in __init__ self.start_session(desired_capabilities, browser_profile) File ".../selenium/webdriver/remote/webdriver.py", line 143, in start_session self.session_id = response['sessionId'] KeyError: 'sessionId' I have no idea if this is some problem with the wires version I compiled with cargo build, the firefox I installed, or something different, I just added the details here for a fuller picture. Basically this bugreport is only about the binary download on the Marionette WebDriver page not working in all cases because of the libc version dependency. Could be that a statically linked version would solve this. For the rest I am not sure if I can investigate much further since there will probably be difficulties installing a dev build of firefox in this CentOS environment, and I can't use a different one for the project I am working on.
Severity: normal → minor
OS: Unspecified → Linux
Hardware: Unspecified → x86_64
It looks to me as if wires is dynamically linked: % ldd wires-0.4.2-linux64 linux-vdso.so.1 (0x00007fff5bb10000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007feecc35a000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feecbfb1000) /lib64/ld-linux-x86-64.so.2 (0x00007feecc90f000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007feecbcb0000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feecbaac000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007feecb88f000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007feecb679000) We probably want to do this for distribution purposes. Different sources (https://internals.rust-lang.org/t/static-binary-support-in-rust/2011/35) suggest linking against the musl C library to be the best option. The following documentation explains how to: https://doc.rust-lang.org/nightly/book/advanced-linking.html#static-linking
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to Andreas Tolfsen (:ato) from comment #1) > We probably want to do this for distribution purposes. Sorry, I meant: We probably want to statically link for distribution purposes.
I suggest we release builds using the musl C library. Rust supports this target when musl-tools is installed on the system. I have done the preparation work for this in https://github.com/mozilla/geckodriver/issues/73. The tracking bug for using Travis to auto-publish new releases is https://github.com/mozilla/geckodriver/issues/72. I will continue to close this bug to allow us to track it in the geckodriver project.
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.