plugin-container ignores LD_LIBRARY_PATH

RESOLVED FIXED in mozilla8



7 years ago
6 years ago


(Reporter: Gyorgy Krajcsovits, Assigned: glandium)



Firefox Tracking Flags

(Not tracked)



(1 attachment, 2 obsolete attachments)



7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100611 Firefox/3.6.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100611 Firefox/3.6.4

Worked in 3.6.3 that I had my custom built libraries in a directory that was not listed in system wide ldconfig, only in LD_LIBRARY_PATH. In 3.6.4 I got: /local/home/egyokra/opt/firefox/plugin-container: error while loading shared libraries: cannot open shared object file: No such file or directory.

Workaround is that I've linked the library into the working directory of firefox.

Reproducible: Always

Steps to Reproduce:
1. Put a lib used by some addon-extension into a new directory.
2. Use LD_LIBRARY_PATH to point to directory.
3. Addon should work in 3.6.3 , and not in 3.6.4.
Actual Results:  
See details.

Expected Results:  
No printout, should work as before.

I've got a company managed old Suse 10 desktop where I don't have root rights, so I need to use my user settings for everything.

I'll take a patch which appends instead of overwriting, but it's a low priority so the core devs aren't likely to fix it.
Component: Shell Integration → IPC
Ever confirmed: true
Product: Firefox → Core
QA Contact: shell.integration → ipc

Comment 2

7 years ago
I don't have the time to prep a build and test it, but I made a small program where I've reproduced this and tested the fix bellow (without the path.get() statement, I just used a string literal). It should be ok, assuming that you meant "append" in the literal sense and did not mean "prepend" :)

After line 50 add inside the ifdef:
#include <stdlib.h>

Instead of
newEnvVars["LD_LIBRARY_PATH"] = path.get();
on line 200, I'd write:
    char* tmp = getenv("LD_LIBRARY_PATH");
    std::string ldpath;
    if(0 != tmp) {
        ldpath = tmp;
    if(0 != ldpath.length()) {
    newEnvVars["LD_LIBRARY_PATH"] = ldpath;
Forgive my ignorance, but why is LD_LIBRARY_PATH being overwritten to begin with?

If I understand the code correctly, it's being set to the location of the plugin-container... but shouldn't that already be in LD_LIBRARY_PATH from the setup done in the script?

Comment 4

7 years ago
I've hit this problem too.

I'm running FF 3.6.4 on a RedHat4.x system.  Since that has old libraries I've copied more recent ones from another system, dropped them into a special directory and started up Firefox through a script that sets LD_LIBRARY_PATH accordingly.  (I've also patched the binary to use a different dynamic loader, but that doesn't matter here).

Because plugin-container ignores LD_LIBRARY_PATH it now fails to start.

As a result of plugin-container failing to start *Firefox hangs completely*!!!
Surely the whole point of plugin-container is to *reduce* hangs, but it is *causing* them!
Matthew, most Linux distros use Firefox-on-XULRunner, which doesn't use the script.

Comment 6

7 years ago
> Matthew, most Linux distros use Firefox-on-XULRunner, which
> doesn't use the script.


To be running Firefox you must already be able to access the relevant libraries for plugin-container.

So pass on any LD_LIBRARY_PATH you have.  *Don't* hard-wire it to what may well be wrong (and certainly *is* wrong for a non-zero set of people).
It is not irrelevant. The standalone glue system used by XULRunner dynamically loads the dependent libraries (libxul etc), so they are not available on the default loader path, and are not (yet) in LD_LIBRARY_PATH.

Comment 8

7 years ago
Still fails at 3.6.7 (I can't set Version in the details)
If it were fixed, the bug would say so. Currently nobody is working on this bug.

Comment 10

7 years ago
A better(?) solution has occurred to me.

This LD_LIBRARY_PATH setting is only there for Linux (it's in an #ifdef OS_LINUX) section.

There is a much better way to get the plugin-container to look in the same directory for its libraries - just set the RUNPATH in the binary to $ORIGIN at link-time.  Then the standard run-time linker will look there regardless of the path to which Firefox was installed. 

(I can't see that the symlink objection expounded in would apply here).


7 years ago
Duplicate of this bug: 595795
My patch on bug 552864 implements the rpath=$ORIGIN suggestion from comment 10, FWIW.

Comment 13

7 years ago
Is this going to make it into some future release anyway ? Like I said, I cannot build firefox myself, but if delivery depends on test, I can give it a shot over the next weekend.
Duplicate of this bug: 644484

Comment 15

7 years ago
I am having this problem too. My gcc is in an alternate path, and I cannot use any plugins now. 
So firefox cannot work on any system with libraries in non standard location?

The funny thing is I am having this problem only in firefox 4.0. On firefox 3.6.15, everything is fine

Comment 16

6 years ago
This thread seems to be for 3.6.X tree. However, I am able to work with 3.6.17 etc., However, I cannot use firefox 4.0 due to this issue.
My glibc is not in /usr/lib/gcc but in an alternate path. With proper LD_LIBRARY_PATH, firefox can start, but plugin-container crashes, leading to firefox crash.
Is there a fix somewhere which will allow me to use firefox 4.0 instead of 3.6 branch?

Comment 17

6 years ago
Any quick workaround for this? I am playing with a plugin for testing AtkPlug/AtkSocket on linux that is only available on GNOME3 stack (that I have installed on /opt/gnome).

Comment 18

6 years ago
I see no point in removing LD_LIBRARY_PATH from the plugins. Iff an admin decides to add shared libs to the runtime path in order to get FF to run, than the plugins will be expected to have the same environment, too.

We use it to get FF 3.6 tun on RHEL4: We se LD_LIBRARY_PATH to inject an gtk2.4 environment and FF works. But flash plugin does not work, because it does not find the supplied gtk environment. In the past we had no problem with it.

Comment 19

6 years ago
I do not think this will be fixed as most users have gcc in /usr/lib/gcc
Very rarely you will find old gcc /usr/lib/gcc and users using a newer version of gcc in /usr/somepath/lib/gcc
So its affecting only a small percentage of users, and typically, bugs, which affect only a small percentage of users are very low priority.
So we are sticking to 3.6 now, and cannot migrate to 4.0.

That said I am wondering, for 4.0 tree this same bug will do or do I need to file a new one

Comment 20

6 years ago
Created attachment 535299 [details] [diff] [review]

Please test this patch.
Assignee: nobody → mh+mozilla

Comment 21

6 years ago
Created attachment 535300 [details] [diff] [review]

Previous patch is probably not completely safe, though it might work. Please use this one.
Attachment #535299 - Attachment is obsolete: true


6 years ago
Attachment #535300 - Attachment filename: diff → bug573958

Comment 22

6 years ago
Created attachment 543068 [details] [diff] [review]
Extend LD_LIBRARY_PATH instead of replacing it during plugin-container initialization

Attachment #543068 - Flags: review?(benjamin)


6 years ago
Attachment #535300 - Attachment is obsolete: true

Comment 23

6 years ago
Could those who have the problem test these builds, that include the patch from this bug:
Attachment #543068 - Flags: review?(benjamin) → review+

Comment 24

6 years ago
Whiteboard: [inbound]
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla8


6 years ago
Depends on: 711144
You need to log in before you can comment on or make changes to this bug.