1216995 - marionette wires linux64 download does not work with all linux64

Status: RESOLVED FIXED

(Remote Protocol :: Marionette, defect)

Description

[Peter Köllner]

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.

Comment 1

[Andreas Tolfsen ❲:ato❳]

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

Comment 2

[Andreas Tolfsen ❲:ato❳]

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

Comment 3

[Andreas Tolfsen ❲:ato❳]

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.