984086 - PR_GetLibraryPath not reliable (guessed, wrong) on Linux

Status: NEW

(NSPR :: NSPR, defect)

Description

[Jarek Czekalski]

User Agent: Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release)
Build ID: 20140212131424



Actual results:

Library paths returned by PR_GetLibraryPath on Linux are hardcoded to "/usr/lib:/lib". This list skips other possible library locations that may be configured on a Linux system. Most notable examples are "/usr/local/lib" and "/usr/lib/i386-linux-gnu" (generally Multiarch triplet on Debian).


Expected results:

My investigation shows there are no tools or functions returning the list of library paths on Linux. The only way to obtain them is parsing /etc/ld.so.conf file, with possible includes.

Mozilla source currently uses PR_GetLibraryPath only in one place, accessible/src/atk/Platform.cpp. This causes bug #743580. A workaround suggested there uses PR_GetLibraryFilePathname to obtain a directory of an already loaded library, which was located by native system call (dlopen).

Another bug report regarding PR_GetLibraryPath deficiency is #469504.

Comment 1

[Wan-Teh Chang]

Attachment: A test program for dlopen on Linux

Jarek:

Thank you for the bug report. I agree the hardcoded default
shared library search path is wrong today. However, I don't
know how to fix this bug. It may be better to simply deprecate
the PR_GetLibraryPath function (and the related PR_SetLibraryPath
function) and document its limitations.

I also looked into how to fix bug 743580. As this test program
shows, if the |file| argument (the first argument) passed to
dlopen() is a relative pathname, dlopen won't use the library
search path. This is why the code in accessible/src/atk/Platform.cpp
needs the library search path.

When I run this test program on Ubuntu x86_64, I get this output:

wtc@fips:~/tmp$ gcc -Wall foo.c -ldl
wtc@fips:~/tmp$ ./a.out
dlopen("/usr/lib/x86_64-linux-gnu/libnss3.so") succeeded
dlopen("libnss3.so") succeeded
dlopen("/usr/lib/x86_64-linux-gnu/nss/libsoftokn3.so") succeeded
dlopen("nss/libsoftokn3.so") failed: nss/libsoftokn3.so: cannot open shared object file: No such file or directory
dlopen("libsoftokn3.so") failed: libsoftokn3.so: cannot open shared object file: No such file or directory

Comment 2

[Jarek Czekalski]

Hello Wan-Teh

It's nice to get an answer to a report from the project chief, thanks! I would offer my help in making the function work properly on Linux (by parsing conf files), but I'm afraid the general problem, on other platforms, would remain valid. So documenting the function limitations would be necessary anyway. In this case extending it to the state of "deprecated" seems to be a good idea. And now fixing that on Linux doesn't seem to be very valuable, because nsPr should be portable, by definition.

I didn't understand what way you suggest to fix the other bug 743580. You only explained the reasons, didn't you? Actually we could remove PR_GetLibraryPath from this part of code, replacing it with the hardcoded paths (we add it there anyway). More complicated cases should be handled properly by the atk-location-guesser fix.

Actually I needed this bug report badly, to be able to mention it in the code in Platform.cpp :)

Comment 3

[Wan-Teh Chang]

Jarek:

I'm sorry my comments about bug 743580 are not clear. I believe
the code in accessible/src/atk/Platform.cpp needs to know the
full pathname of the module because dlopen("gtk-2.0/modules/libfoo.so", ...)
doesn't use the library search path. So, Platform.cpp needs
either the library search path or the directory where the
module is likely to be in.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee is inactive on Bugzilla, so the assignee is being reset.