558911 - Rev3 Fedora permaorange: jsctypes-test/unit/test_jsctypes.js | Error: couldn't open library (missing libm.so)

Status: RESOLVED FIXED

(Release Engineering :: General, defect, P2)

Description

[Armen [:armenzg]]

TEST-UNEXPECTED-FAIL | /home/cltbld/talos-slave/mozilla-central-fedora-debug-u-xpcshell/build/xpcshell/tests/jsctypes-test/unit/test_jsctypes.js | test failed (with xpcshell return code: 3), see following log:
TEST-UNEXPECTED-FAIL | (xpcshell/head.js) | Error: couldn't open library - See following stack:

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1271101039.1271103438.26319.gz

Comment 1

[Phil Ringnalda (:philor)]

According to bug 554934 comment 14, the solution to this was going to be to get libm.so installed on the Fedora slaves.

If instead you have changed your minds about that, please put the bug in Core: js-ctypes, rather than the dumping ground of Core: General, with maybe an explanation that you have decided you cannot tolerate the presence of libm.so.

Comment 2

[[e-mail]]

Last I read, jhford was seeing about getting libm on those?

Comment 3

[Armen [:armenzg]]

(In reply to comment #1)
> According to bug 554934 comment 14, the solution to this was going to be to get
> libm.so installed on the Fedora slaves.
> 
> If instead you have changed your minds about that, please put the bug in Core:
> js-ctypes, rather than the dumping ground of Core: General, with maybe an
> explanation that you have decided you cannot tolerate the presence of libm.so.

No need to get like that. I had lost track of it. We will keep this bug for this purpose.

(In reply to comment #2)
> Last I read, jhford was seeing about getting libm on those?

I will work on this but I will probably need some help to get it done right.

I found John's comment.
> John Ford wrote:
> > (In reply to comment #7)
> > > Created an attachment (id=434883) [details] [details] [details]
> > > xpcshell - test_jsctypes.js and xpcshell/head.js
> > 
> > This test is failing to load a specific system library.  Perhaps libm.so is
> > called something else on fedora or is not in the path?
> > See:
> > http://mxr.mozilla.org/mozilla-central/source/js/ctypes/tests/unit/test_jsctypes.js.in#1786
> 
> $ yum -q whatprovides */libm.so
> glibc-devel-2.11-2.i686 : Object files for development using standard C
>                         : libraries.
> Repo        : fedora
> Matched from:
> Filename    : /usr/lib/libm.so
> 
> $ rpm -qi glibc-devel
> package glibc-devel is not installed
> 
> It looks like we do not have libm.so on the system.  Instead of installing the
> development package, we could copy that library from the rpm using
> yumdownloader and rpm2cpio.

Comment 4

[Zack Weinberg (:zwol)]

The offending code is actually here: http://mxr.mozilla.org/mozilla-central/source/toolkit/components/ctypes/tests/unit/test_jsctypes.js.in#2279

You do have libm on these systems, I assure you, it's just that "libm.so" is not its official name.  This patch would resolve the problem without needing to modify the system configuration:

 #elifdef XP_UNIX
-  let syslib = ctypes.open("libm.so");
+  let syslib = ctypes.open("libm.so.6");

This does make the name Linux-specific, unfortunately (e.g. Solaris uses libm.so.2 if I remember correctly).  We don't seem to have XP_ defines that can distinguish Linux from other Unix, though, so maybe that's the best we can do (a small number of places *use* XP_LINUX but it isn't consistently *defined* anywhere).

If we are prepared to make system configuration changes, but for some reason do not want to install glibc-devel, "ln -s /lib/libm.so.6 /usr/lib/libm.so" would be sufficient.  The bare .so name is always just a symlink to the real library.

Comment 5

[Armen [:armenzg]]

Zack, does this look?

[cltbld@talos-r3-fed-001 ~]$ ls -l /lib/libm*
-rwxr-xr-x 1 root root 233056 2009-11-05 05:07 /lib/libm-2.11.so
lrwxrwxrwx 1 root root     12 2010-01-20 11:00 /lib/libm.so.6 -> libm-2.11.so
-rwxr-xr-x 1 root root 243592 2009-08-20 15:34 /lib/libmultipath.so
[root@talos-r3-fed-001 ~]# ln -s /lib/libm.so.6 /usr/lib/libm.so

I have made these changes on the staging machines and let them run and hopefully this will be fixed.

Thanks for looking into this!

Comment 6

[Zack Weinberg (:zwol)]

I *think* that's the right thing, but just to be sure, do this:

$ ls -l /usr/lib/libm.so
lrwxrwxrwx 1 root root 14 Apr 26 09:23 /usr/lib/libm.so -> /lib/libm.so.6

You should get the same output, except of course for the date.

I'm a little concerned that this manually-created symlink will not survive upgrades and other configuration changes.  Installing glibc-devel (and adding it to your list of packages that should be installed) would have been my solution.

Comment 7

[Armen [:armenzg]]

Attachment: add symlink to libm.so

Comment 8

[[e-mail] (:bhearsum)]

(In reply to comment #4)
> The offending code is actually here:
> http://mxr.mozilla.org/mozilla-central/source/toolkit/components/ctypes/tests/unit/test_jsctypes.js.in#2279
> 
> You do have libm on these systems, I assure you, it's just that "libm.so" is
> not its official name.  This patch would resolve the problem without needing to
> modify the system configuration:
> 
>  #elifdef XP_UNIX
> -  let syslib = ctypes.open("libm.so");
> +  let syslib = ctypes.open("libm.so.6");
> 
> This does make the name Linux-specific, unfortunately (e.g. Solaris uses
> libm.so.2 if I remember correctly).  We don't seem to have XP_ defines that can
> distinguish Linux from other Unix, though, so maybe that's the best we can do
> (a small number of places *use* XP_LINUX but it isn't consistently *defined*
> anywhere).
> 
> If we are prepared to make system configuration changes, but for some reason do
> not want to install glibc-devel, "ln -s /lib/libm.so.6 /usr/lib/libm.so" would
> be sufficient.  The bare .so name is always just a symlink to the real library.

Are we not going to run into this on Fedora installs in the wild?

Comment 9

[Zack Weinberg (:zwol)]

(In reply to comment #8)
> 
> Are we not going to run into this on Fedora installs in the wild?

Maybe not exactly *this*, but yes, code that uses ctypes to access system shared libraries on Linux is going to have to be aware of how sonames work.  It might be in-scope for ctypes to help out a bit with libraries that are commonly wanted and don't have consistent cross-platform names, but I don't know how best to present that information at the moment.

I would *hope* that real code does not need to get at libm specifically, as we already have the native JS Math object for what it does.

Comment 10

[[e-mail] (:bhearsum)]

I just chatted with Ehsan about this, and he suggested wrapping the loading in exception handling code, and falling back on loading libm.so.6 if the libm.so load fails. To me, this seems like a better solution that allows this test to pass in more places.

Dan/Phil/Zack, what do you guys think?

Comment 11

[[e-mail]]

We could have a variety of alternative .so names, yes. The point of that particular test is just to see whether a system library can be loaded; any library will do.

A patch for that would be pretty simple.

Comment 12

[[e-mail] (:bhearsum)]

Assigning to dwitte based on irc conversation.

Comment 13

[[e-mail] (:bhearsum)]

Comment on attachment 441546 [details] [diff] [review]
add symlink to libm.so

We're going to make the test more robust rather than modify the system.

Comment 14

[(no longer active)]

Attachment: Patch (v1)

I had written a patch for this, but forgot to attach it.  So, I'm stealing this from dwitte, but I'm shamelessly asking for his review.

Comment 15

[[e-mail]]

Comment on attachment 441687 [details] [diff] [review]
Patch (v1)

r=dwitte, thanks!

Comment 16

[timeless]

http://hg.mozilla.org/mozilla-central/rev/664558d0e3c5