Servo: Nigthly won't start on some linux distros : fedora 24 / 23, debian testing

[lhirlimann]

[ludo@Oulanl ~]$ cd servo/
[ludo@Oulanl servo]$ ./runservo.sh 
./servo: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
[ludo@Oulanl servo]$ 

[Manishearth]

You may need to install openssl.

[lhirlimann]

it's installed :
[ludo@Oulanl servo]$ rpm -qa |grep openssl
openssl-devel-1.0.2h-1.fc24.x86_64
openssl-1.0.2h-1.fc24.x86_64
openssl-libs-1.0.2h-1.fc24.i686
openssl-libs-1.0.2h-1.fc24.x86_64

[Manishearth]

Looks like this is a duplicate of https://github.com/servo/servo/issues/12017. We'll look into this, thanks for the report!

[divingdeer]

I can confirm this issue. It seems the problem is caused by the version of OpenSSL provided by Fedora.

Output of rpm -qa | grep openssl:

openssl-libs-1.0.2h-1.fc24.x86_64
openssl-devel-1.0.2h-1.fc24.x86_64
openssl-libs-1.0.2h-1.fc24.i686
openssl-1.0.2h-1.fc24.x86_64

Output of /usr/lib64% ls | grep libssl:

libssl3.so
libssl.so
libssl.so.10
libssl.so.1.0.2h

I tried to work around the error by linking libssl.so.1.0.0 to libssl.so and libcrypto.so.1.0.0 to libcrypto.so

But that does not work either:

./servo: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./servo)
./servo: /lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.1d' not found (required by ./servo)
./servo: /lib64/libssl.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./servo)

[anisse]

The issue is the same on Fedora 23.

[Coder206]

I had no issues running on a clean version of Fedora 24 by compiling it...

[lhirlimann]

Same here, it's a packaging issue most likely.

[Coder206]

@lhirlimann I am also experiencing the issues you described but I am still able to run it if i compile it myself.

[frewsxcv]

Possibly related issue: https://github.com/sfackler/rust-openssl/issues/401

[est31]

This sounds like an issue godotengine had where they have built the binaries on an ubuntu travis instance, and then fedora users downloaded and got a similar problem: https://github.com/godotengine/godot/issues/1391

Out of some reason, Fedora has a custom soname for the openssl library, and as the soname gets stored at linking time, the soname the binary has stored differs from the soname that is expected on fedora. It essentially means that there is no binary compatibility between fedora and non fedora systems, for programs that dynamically link to openssl.

If this is the issue, and it really looks like that, you'd either need to statically link in openssl, or publish a separate build for fedora.

[RalfJung]

This bug is not specific to Fedora at all. I am getting the same error on Debian testing:

$ ./runservo.sh
./servo: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory
$ find /usr/lib -name "libssl*"
/usr/lib/i386-linux-gnu/i686/cmov/libssl.so.1.0.2
/usr/lib/i386-linux-gnu/libssl.so.1.0.2
/usr/lib/x86_64-linux-gnu/libssl3.so.1d
/usr/lib/x86_64-linux-gnu/libssl3.so
/usr/lib/x86_64-linux-gnu/libssl.so.1.0.2
/usr/lib/x86_64-linux-gnu/pkgconfig/libssl.pc
/usr/lib/x86_64-linux-gnu/libssl.so
/usr/lib/x86_64-linux-gnu/libssl.a

EDIT: The problem seems to be in servo requiring a too specific version of OpenSSL:
$ ldd servo | grep ssl
libssl.so.1.0.0 => not found

This is using the version downloaded from https://servo-builds.s3.amazonaws.com/index.html

[est31]

What's the output of objdump -x /usr/lib/x86_64-linux-gnu/libssl.so | grep SONAME ?

[anisse]

SONAME libssl.so.10

[ZaWertun]

I have just the same SONAME on Fedora 23.

[anisse]

FYI:
https://apps.fedoraproject.org/packages/openssl
You can get the RPMs here:
F23:
http://koji.fedoraproject.org/koji/buildinfo?buildID=759832
F24:
http://koji.fedoraproject.org/koji/buildinfo?buildID=759831

Edit: you probably want to look at openssl-libs and openssl-devel

[RalfJung]

@est31

$ objdump -x /usr/lib/x86_64-linux-gnu/libssl.so | grep SONAME
  SONAME               libssl.so.1.0.2

[est31]

Its "libssl.so.1.0.0" for me on ubuntu 16.04, and for me the nightly works. So the issue still seems to be connected to the soname, although not isolated to fedora.

[ammarnajjar]

+1
fedora24, same issue:

$ sudo dnf info openssl
Last metadata expiration check: 1:21:45 ago on Mon Jul  4 18:36:54 2016.
Installed Packages
Name        : openssl
Arch        : x86_64
Epoch       : 1
Version     : 1.0.2h
Release     : 1.fc24
Size        : 817 k
Repo        : @System
From repo   : @commandline
Summary     : Utilities from the general purpose cryptography library with TLS implementation
URL         : http://www.openssl.org/
License     : OpenSSL
Description : The OpenSSL toolkit provides support for secure communications between
            : machines. OpenSSL includes a certificate management tool and shared
            : libraries which provide various cryptographic algorithms and
            : protocols.

$ ls -l /usr/lib/libssl*
lrwxrwxrwx. 1 root root   16 May  3 18:32 /usr/lib/libssl.so.10 -> libssl.so.1.0.2h
-rwxr-xr-x. 1 root root 434K May  3 18:32 /usr/lib/libssl.so.1.0.2h

$ objdump -x /usr/lib/libssl.so.1.0.2h | grep SONAME
  SONAME               libssl.so.10

and creating a symlink like:

$ sudo ln -s /usr/lib/libssl.so.1.0.2h /usr/lib/libssl.so.1.0.0

does not solve the issue.

[Shihira]

I have the same issue. I tried to download those so files here, and extract them into the servo directory. Then launch Servo with:

[shihira Servo]$ LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$PWD ./runservo.sh

Anyway finally it launched, but SSL seems not working though, for some version faults. Hardly load a page.

[elennaro]

Same issue.
Is there a workaround?

[meghprkh]

I downloaded the files from above and added them to my ld.conf but it prints something like:

[megh@theunknown servo] $ ./runservo.sh 
./servo: /home/megh/Downloads/servo/lib64/libcrypto.so.1.0.0: no version information available (required by ./servo)
./servo: /home/megh/Downloads/servo/lib64/libcrypto.so.1.0.0: no version information available (required by ./servo)
./servo: /home/megh/Downloads/servo/lib64/libssl.so.1.0.0: no version information available (required by ./servo)

Unhandled error occured 
ReferenceError: navigator.mozSettings API is not available

[meghprkh]

Okay got a temporary solution, link https://www.reddit.com/r/linux/comments/4qqc6g/servo_developer_preview_builds_available/d4v2dqh

[ollyja]

Tried last nightly. same issue on Fedora 24.

[fabiand]

I think the nightlies need to be built against a newer openssl to work smoothly on Fedora.
Maybe another travis job can be added?

[est31]

One of the ways to solve the soname problems once and for all would be to build flatpaks and distribute them instead: http://flatpak.org/developer.html http://flatpak.org/

openssl would I think be packaged via the runtime, so it could be updated without the intervention of servo.

The only requirement is that flatpak and the runtime are installed, but fedora already ships with flatpak, and debian based distros have a flatpak ppa.

[fabiand]

That's actually an awesome idea!

[anisse]

Why not simply bundle libssl ? This is a nightly, and software you shouldn't be running longer than a day without updating. Or am I missing something ?

[jdm]

@anisse There's been a lot of discussion on that topic at https://groups.google.com/forum/#!topic/mozilla.dev.servo/3mfkRehXAo4 .

[dumindu]

This is still happening :(

[StefanoD]

Same issue with Fedora 25:

bash-4.3$ sudo dnf info openssl
Installed packages
Name : openssl
Arch : x86_64
Epoch : 1
Version : 1.0.2j
Release : 3.fc25

As someone stated: A flatpack package would be cool!

[thangarajj]

Can confirm that this issue remains on Fedora 25 on today's build.

[vatrat]

Issue is still around on Fedora 25. I'll try to compile.

[ameenross]

Yup, I recently got rid of my Servo clone and started gettings the nightlies. Experiencing this error now.

[funghetto]

Same on debian sid.

[gpavinteractiv]

Fedora 25, today's buid : Still

[mcepl]

The same goes for RHEL-7 … when I do symlinks, it still breaks, because apparently proper symbols are not there.

[StefanoD]

By the way: You could do a snap package. It is stable (version 1.0+) and runs on Fedora as well.

[daboross]

I'm not sure if I have a missing dependency or I'm running into this issue, but here's my output for the nightly download:
`` $ ./servo ./servo: /usr/lib64/libcrypto.so.1.0.0: versionOPENSSL_1.0.0' not found (required by ./servo)
./servo: /usr/lib64/libcrypto.so.1.0.0: version OPENSSL_1.0.1d' not found (required by ./servo) ./servo: /usr/lib64/libcrypto.so.1.0.0: versionOPENSSL_1.0.1' not found (required by ./servo)
./servo: /usr/lib64/libssl.so.1.0.0: version OPENSSL_1.0.0' not found (required by ./servo) ./servo: /usr/lib64/libssl.so.1.0.0: versionOPENSSL_1.0.1' not found (required by ./servo)
$ ldd servo
./servo: /usr/lib64/libcrypto.so.1.0.0: version OPENSSL_1.0.0' not found (required by ./servo) ./servo: /usr/lib64/libcrypto.so.1.0.0: versionOPENSSL_1.0.1d' not found (required by ./servo)
./servo: /usr/lib64/libcrypto.so.1.0.0: version OPENSSL_1.0.1' not found (required by ./servo) ./servo: /usr/lib64/libssl.so.1.0.0: versionOPENSSL_1.0.0' not found (required by ./servo)
./servo: /usr/lib64/libssl.so.1.0.0: version `OPENSSL_1.0.1' not found (required by ./servo)
linux-vdso.so.1 (0x00007ffd56134000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2275019000)
libdbus-1.so.3 => /usr/lib64/libdbus-1.so.3 (0x00007f22753d5000)
...
$ openssl version
OpenSSL 1.0.2k 26 Jan 2017
$ objdump -x /usr/lib64/libssl.so.1.0.0 | grep SONAME
SONAME libssl.so.1.0.0
````

[juhp]

Or a flatpack :)

So what OS version are the nightly snapshots built on? And why? :)

[MGageMorgan]

Will this be fixed by July 1st, 2017? I wanna experience the one thing closest to a browser written in HTML and Rust, but can't because I can't compile or run it (both fail for me).

[axvr]

This is a problem which has occurred due to the machine which creates the builds using outdated versions (from 2013) of the OpenSSL libraries (libssl and libcrypto on Fedora). There are currently only two solutions to this problem:

1. Build Servo on the system you plan to use it on. This will link the new libraries to your own build of Servo automatically. This is currently the best method to run Servo on systems which do not hold copies of the OpenSSL 1.0.0 libraries.
2. Downgrade your libraries NOT RECOMMENDED UNDER ANY CIRCUMSTANCE. This would be difficult to do on Fedora as the repositories do not hold the 1.0.0 packages for the OpenSSL libraries any more (they were available on Fedora 13). These would have to be compiled on your system independent of a package manager, as DNF will not allow you to do so.

Symbolic linking will not solve this issue it will simply cause the problem that @daboross was having, where the libraries used by the official nightly build of Servo still do not actually exist on your system.

[StefanoD]

Naive question: Why is the OpenSSL version of the build server not getting updated? This would be actually the third solution @axvr

[MGageMorgan]

@axvr It won't build on my machine, tried three times last night :(

I am hijacking libraries from ubuntu debs as per a reddit thread, but Fedora 13? How do you maintain a build machine without updates for eons like that? So the build machine hasn't been updated in 4 YEARS? That's a long time, amigo.

[StefanoD]

I'm actually puzzled why the build server is not some LTS distribution like Ubuntu LTS.

[MGageMorgan]

@StefanoD No, that's the only logical solution, and it's the one that takes the least amount of time on the part of us and the maintainers. (Apt install or dnf install, anyone?)

[MGageMorgan]

@StefanoD Maybe it is and everyone just forgot to update it from Ubuntu 12.04

[jdm]

https://github.com/servo/saltfs/issues/462

[MGageMorgan]

@jdm Elaborate?

[jdm]

That is an issue for our build infrastructure titled "Update build machines to use Ubuntu 16.04".

[MGageMorgan]

@jdm Looking at SaltFS, and that issue, looks like integrating with the init system came crashing down. I don't know much about SaltFS, but if by looking at that says anything to me, it would be that relying on the underlying OS isn't a good idea. Especially because Linux components are always changing if not breaking.

I'm learning rust, and wondering if my next project should involve init scripts...

[MGageMorgan]

@jdm yeah. I got that. I feel there should be a way to write the same init script to run on systemd, initd, upstart, etc. Like a binding or something...

[Asfhy]

I'm on Manjaro Linux (Arch derivate) and I managed to make it run after using prelink on the downloaded servo binary. I mean, my way of getting the nightly build runing is:

1- Download the build
2- Extract the build on the servo folder
3- Use a terminal to navigate to the servo folder and run "sudo prelink servo"
4- Perlink finds the needed libraries and link them to the binary, so it ends in a second or two without errors, now "./servo" opens the window and no more errors about libraries not found are thrown.

PS: That obviuly means you need to install prelink on your system.

[MGageMorgan]

@Asfhy Never heard of it, but I'll go look that up soon. There's a lot more I could do with a tool like that outside the scope of servo if it exists and works.

[daboross]

Prelink looks like an awesome tool, but sadly it does not fix it on all systems. Output from running prelink on the binary on Gentoo:

$ sudo prelink servo 
prelink: /usr/lib32/misc/glibc/getconf/POSIX_V7_ILP32_OFFBIG: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: /usr/lib32/misc/glibc/getconf/XBS5_ILP32_OFF32: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: /usr/lib32/misc/glibc/getconf/XBS5_ILP32_OFFBIG: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: /usr/lib32/misc/glibc/getconf/POSIX_V7_ILP32_OFF32: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: /usr/lib32/misc/glibc/getconf/POSIX_V6_ILP32_OFFBIG: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: /usr/lib32/misc/glibc/getconf/POSIX_V6_ILP32_OFF32: Using /lib32/ld-linux.so.2, not /lib/ld-linux.so.2 as dynamic linker
prelink: servo: Could not parse `./servo: /usr/lib64/libcrypto.so.1.0.0: version `OPENSSL_1.0.0' not found (required by ./servo)'

[MGageMorgan]

@dabpross Don't worry, have yet to actually try it ;)

[MGageMorgan]

*@daboross

[fabiand]

I've created a small Makefile to build a flatpak wrapping the servo nightlies, see

• https://github.com/fabiand/flatpak-servo
• https://dummdida.tumblr.com/post/161401019450/flatpak-ing-servo-nightly

We could take it from here and use this (or alike) in the servo nightly build process, and push those builds to flathub (once it's back online).

[StefanoD]

@fabiand Great! I think, you have to make a PR.

[MGageMorgan]

I think that's awesome. Even if it doesn't make it in, long as it works and is maintained, I would be happier using a tool like this alone than what's currently available.

Cheers!

M. Gage Morgan

---

Christoffen OSWorks LLC co-founder, CEO, and lead architect.

/**

• Just note that my opinion will

• NEVER reflect my company, which I

• hope to keep neutral in terms of

• public relations with other entities.

**/

On Sat, Jun 3, 2017 at 5:15 PM -0400, "Stefano" [e-mail] wrote:

@fabiand Great! I think, you have to make a PR.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.

[dralley]

What is the progress on this?

[jdm]

No progress.

[nox]

Is this still an issue?

[ojab]

Yep, reproducible on Fedora-26 w/ all updates and latest servo nightly.

[MGageMorgan]

Wow, missed my July 1st deadline XD

[ZanderBrown]

This is still reproducible on Fedora 27 (Beta) with the latest nightly

[jurf]

Nothing changed with F27 coming out of Beta.

[ZanderBrown]

Just checked latest nightly on F27:

./servo: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory

[lnicola]

For anyone interested, the official servo builds can be tested on Arch by installing openssl-1.0. It can be used side by side with openssl 1.1.

[fabiand]

Good idea. That might actually also work on Fedora by dnf install compat-openssl10

[ojab]

Unfortunately it won't help on Fedora, compat-openssl10 contains libssl.so.1.0.2m, while servo requires libssl.so.1.0.0.

[fabiand]

Thanks for testing this so quickly. Darn.

[RalfJung]

To me this sounds like a build machine issue: For some reason, the machine doing the build uses a pretty old version of libssl, namely some variant of 1.0.0, and hence that's what the binary links to. The OpenSSL website says

The 0.9.8, 1.0.0 and 1.0.1 versions are now out of support and should not be used.

So, probably what should happen is that the build machine gets updated to a non-legacy version of OpenSSL?

[ZanderBrown]

Seems reasonable, anyone have the ability to do that?

[anisse]

@RalfJung @ZanderBrown : this would be a first step indeed, see @jdm 's comment:

servo/saltfs#462

Note that it does not mean the dogmatic position of not bundling openssl on Linux (but doing it on Mac, Windows) would change; you'd need to reach a consensus on that, too.

[jdm]

I suspect that we would need to update the version of openSSL we use within the build as well, and that may require updating our Network stack which is an open problem right now.

[RalfJung]

Servo compiles on my system against OpenSSL 1.1 just fine.

[jdm]

I've filed https://github.com/servo/saltfs/issues/824 to look into whether we can upgrade the version of OpenSSL that's present on our nightly build machines.

[roberto68]

same error fedora 29 - it'd be good to bundle that lib into the project

[northivanastan]

Still have the error on Debian 9.