Closed Bug 573958 Opened 11 years ago Closed 10 years ago

plugin-container ignores LD_LIBRARY_PATH


(Core :: IPC, defect)

Not set





(Reporter: krajo, Assigned: glandium)




(1 file, 2 obsolete files)

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
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?
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.
> 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.
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.
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).
Duplicate of this bug: 595795
My patch on bug 552864 implements the rpath=$ORIGIN suggestion from comment 10, FWIW.
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
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
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?
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).
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.
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
Attached patch Patch (obsolete) — Splinter Review
Please test this patch.
Assignee: nobody → mh+mozilla
Attached patch Patch (obsolete) — Splinter Review
Previous patch is probably not completely safe, though it might work. Please use this one.
Attachment #535299 - Attachment is obsolete: true
Attachment #535300 - Attachment filename: diff → bug573958
Attachment #535300 - Attachment is obsolete: true
Could those who have the problem test these builds, that include the patch from this bug:
Attachment #543068 - Flags: review?(benjamin) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla8
Depends on: 711144
You need to log in before you can comment on or make changes to this bug.