Closed Bug 304655 Opened 19 years ago Closed 7 years ago

it should be possible to set the rpath on all mozilla-products (including the binary-distributions)

Categories

(Firefox Build System :: General, defect)

Product:
Firefox Build System
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: gpp666_999, Unassigned)

Details

Attachments

(1 file)

Patch for 1.7.12 that sets rpath if LIBRUNPATH environment variable is set
3.45 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050813 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050813 Firefox/1.0.6

I use gentoo and there is the possibility to install mozilla, mozilla-firefox
and so on simultanious, but of course in different directories (probably other
distributions have the same possibility), and to ensure that all the programs
resolve at run-time all the corresponding paths are added to ld.so.conf, which
in turn brings the problem.
In this case all the programs, which link somehow to mozilla-products will link
at run-time to the libraries in the path, which comes first in ld.so.conf. 
This is only part of the problem, if the mozilla-libraries don't have rpath and
are not in the ldpath they will not find their own libraries at run-time. 
You could look at http://bugs.gentoo.org/show_bug.cgi?id=100597 about more
detailed explanation and for some patches, which are only hacks around this.
What are the consequences of this, borked programs and crashes, of all what
depends on anything mozilla, because of erroneous run-time linking.

Reproducible: Always

Steps to Reproduce:
1.install for example nss nspr and gecko-sdk and mozilla-firefox
2.install evolution, gaim-encryption, mplayerplug-in
3.

Actual Results:  
On gentoo this will bork the run-time library resolution, meaning it will not be
the way it was at compile time. I suppose it will be the same situation on all
other distributions.

Expected Results:  
Deterministic run-time library resolution of all mozilla-products.
for tracking purpose does not appear to be gentoo specific why I (Anarchy)
requested it be sent upstream. 
The correct solution for this bug, as it has been since the beginning of time,
is to use the run-mozilla script (called from the firefox script) to set up
LD_LIBRARY_PATH before launching the firefox binary.
Ok, let say it this way (reinterprting you) ... all programs, which link against
us (understand mozilla) are to be damned, we work - the others don't..., not our
problem.
This is to be concluded from set the LD_LIBRARY_PATH and run mozilla.
What about galeon, epiphany or evolution, mplayerplug-in should they also export
LD_LIBRARY_PATH and run as you want it, because even if they make it right and
they are making it right setting the rpath to ensure that they are linking
correct, alas without setting your lovely LD_LIBRARY_PATH your libraries will
not correctly resolve to themselves, pity....and setting it will resolve them to
sth, but would this be the correct thing?
I don't know, who have commented but this was similar to m$'s way of doing the
things.
And there was a resolved bug about setting the rpath for the NSS/NSPR-packages
for opensolaris, so I will ignore for now this types of comments:), hoping for
the best.
(In reply to comment #3)
> Ok, let say it this way (reinterprting you) ... all programs, which link
> against us (understand mozilla) are to be damned, we work - the others don't..., not our problem.

Further examples are programs linking against libgtkembedmoz, like devhelp, for example on FreeBSD.
Either each such program requires a shell wrapper to set LD_LIBRARY_PATH, or run ldconfig which defeats the whole purpose of this feat.
For example with a test-mozembed.c file we ought to be able to do:

gcc test-mozembed.c -o test-mozembed `pkg-config --cflags --libs mozilla-gtkmozembed gtk+-2.0`
./testmozembed

and actually have it "Just Work"tm. That is the purpose of the pkg-config system after all.

The problem of course is that the libembedmoz.so doesn't know how to find the other mozilla libs that it needs. Distros hack around this issue by adding ${moz_libdir} to the global ldconfig path. Which of course means that it works with either mozilla or firefox but not both (because one or the other must come first in the ld library search path).

Of course the correct solution is simply to link libembedmoz.so using -Wl,-rpath,${moz_libdir}. That way it can find the other libs that it needs.

(where moz_libdir=/usr/lib/mozzilla or where ever the distro decides to put it)

On a related note, pkg-config --libs mozilla-gtkmozembed should give us back -Wl,-rpath,${moz_libdir} too so that the program we compile can find the libembedmoz.so library in the first place. Some distros (eg gentoo) correct this mistake, but others do not. People can (and do) hack around this issue by specifying it manually, however they cannot make up for the missing -rpath for libembedmoz.so itself.
I'm think everyone understands the pros & cons of using rpath.  Historically, m.o. has avoided the use by default but afaik, that doesn't preclude any other distributors from using rpath in their own builds.  

Has anyone tested to see what happens when you add -Wl,-rpath,/my/special/dir to LDFLAGS when running configure?  I'm not certain about the pkg-config embedding case, but adding those flags should "Just Work(tm)" for the binaries that are built inside the mozilla tree.
(In reply to comment #6)
> Has anyone tested to see what happens when you add -Wl,-rpath,/my/special/dir
> to LDFLAGS when running configure?  I'm not certain about the pkg-config
> embedding case, but adding those flags should "Just Work(tm)" for the binaries
> that are built inside the mozilla tree.

I just ran a test and the result looks promising! Thanks for pointing out the obvious...
I'll run real tests on Monday at work and report back.

I think that the solution to this is more using the $ORIGIN rpath-type of tags, which don't have the cons of the normal solution, there are some patches in the already mentioned gentoo-bug, but the problem is that I do not know how to hack around the nss/nspr sedding the $ORIGIN tags, all the other libraries and executables could be linked in this way and if someone is using --with-system-nss, this will not be problem for him. And $ORIGIN type of tags are already used in all the java packages, so I don't think it is really a problem adding them to mozilla.

As to the pkg-config files, you could simply add -Wl,-R${mozlibdir} there and most of the application will pick it automatically from there.
> > Has anyone tested to see what happens when you add -Wl,-rpath,/my/special/dir
> > to LDFLAGS when running configure?

Hm, it looks like it works for gtkembedmoz, but not for some of the others:
# yelp-bin
/usr/libexec/ld-elf.so.1: Shared object "libnspr4.so" not found, required by "libplds4.so"
(of course yelp has been compiled with -rpath, too)

It looks like libplds4.so didn't get compiled with -rpath:
# readelf -a /usr/X11R6/lib/mozilla/libplds4.so | grep PATH
#

Or is this expected behaviour?
OTOH, this build together with tweaking pkg-config was sufficient to make 'devhelp' run without a shell-wrapper.

Now I'm a bit confused. Just for the record, could somebody please point out the cons of using -rpath to me? Is there anything else apart from being able to choose which set of libs to use through LD_LIBRARY_PATH?
So, I tested this and adding the rpath flags to LDFLAGS works out as expected with the exception of the pkgconfig files.  I built against a "system installed" NSPR using:

env LDFLAGS='-Wl,-rpath,/usr/cls/root/lib -Wl,-rpath,${mozappdir}' ../mozilla/configure --with-system-nspr --with-nspr-prefix=/usr/cls/root

(along with the standard mozconfig options)

After setting MOZILLA_FIVE_HOME to /usr/cls/root/lib/firefox-1.6a1, I was able to run the installed binaries without using the run-mozilla.sh script.  The NSPR libs do not contain any rpath info but that's only because they were prebuilt.  The NSS libraries do not contain rpath info because NSS doesn't use the given LDFLAGS or CFLAGS (bug 101249).

> Now I'm a bit confused. Just for the record, could somebody please point out
> the cons of using -rpath to me? Is there anything else apart from being able to
> choose which set of libs to use through LD_LIBRARY_PATH?

I believe the primary issue is that on Linux, rpath takes precedence over LD_LIBRARY_PATH.  I just verified that using strace.  So, if m.o. tried to distribute generic builds that used rpath, those generic builds would search the hardcoded path first.  If there was an incompatible library installed into that path (say from another FF or galeon installation), then the m.o. builds would not work.  So, for m.o., the problem is avoided by not using rpath.  However, that doesn't stop any other distributors from using rpath (provided that they can work around the issue).

Btw, the old Red Hat rpms that blizzard used to distribute used rpath at one point.  IIRC, the use of rpath was removed when people weren't able to build a new version of the rpm because the older version was installed with an incompatible version of libxpcom.so .

At this point, I think that the only thing left to do is to come up with a way to add flags to the pkgconfig files.  I'm not convinced that blindly adding the rpath flags is the way to go.   (There's also the age-old NSS build issues but I don't see those changing any time soon.)

I think that the problem is security and not incomapatiblity, because I don't see how mozilla and galeon could install in the same folder or install there incompatible system libraries, moreover epiphany and galeon are using rpath to work around the mozilla problems by default. 
It is an issue if root for example installs mozilla in world writable place, in this case someone could install there say his own copy of libc and compromise the system.
>Btw, the old Red Hat rpms that blizzard used to distribute used rpath at one
>point.  IIRC, the use of rpath was removed when people weren't able to build a
>new version of the rpm because the older version was installed with an
>incompatible version of libxpcom.so .
I'm not sure if I understand this, but I don't understand how rpms are built, as on gentoo there are no such problems and it seems to me, that it has sth to do with the bug about the missing soversions https://bugzilla.mozilla.org/show_bug.cgi?id=53727
I'm using the patches from the gentoo-bug and the patched pkgconfig-files and building all the nss/nspr/gecko-sdk/mozilla-dependancies against firefox and I should say that the stability is greatly increased, in comparison to say ubuntu 5.10
Ok I now see, what do you meant with:
>Btw, the old Red Hat rpms that blizzard used to distribute used rpath at one
>point.  IIRC, the use of rpath was removed when people weren't able to build a
>new version of the rpm because the older version was installed with an
>incompatible version of libxpcom.so .
It is because LD_LIBRARY_PATH is the incorrect solution, it will pick the old libraries on compile and link, which could bring only trouble.
> It is because LD_LIBRARY_PATH is the incorrect solution, it will pick the old
> libraries on compile and link, which could bring only trouble.

That is incorrect.  First, LD_LIBRARY_PATH (from run-mozilla.sh) is only used at runtime, not build time.  Second, LD_LIBRARY_PATH can be changed and overridden whereas rpath cannot so any such problem could have been worked around in the build script.

It's not a security issue.  No one is advocating world-writable system directories.

Yes, the lack of soversioning is part of the general system-installed library problem.  The NSPR libraries are installed into /usr/lib when given --prefix=/usr .  I've seen some rpms which install libxpcom & the NSS libraries into /usr/lib as well since they were used by multiple programs.  None of those libraries use the standard versioning mechanism so it is very possible for programs to pickup an incompatible version of the library. 

Back to the original problem, the gentoo patches hardcode paths as well use some gentoo specific features.  That's not an acceptable soltuion.  As I demonstrated, you can get coverage of most of the tree by passing LDFLAGS to configure.  For the pkgconfig problem, I'm willing to review a patch that doesn't hardcode values.  For the NSS issue,  we will need to come up with something that's acceptable for the NSS team as we've been fighting the issue of passing down build values for years.

Yes, now I completely agree with you (it shows only my ignorance on the way the other distro work around this and I thought of LDFLAGS, when I wrote LD_LIBRARY_PATH :) and understand what you mean.
As I said in the beginning these are "some patches, which are only hacks around this", which only work because of gentoo specifics.
In fact if most of the libraries were proper soversioned, there would have been no problems installing them in /usr/lib and there would have been no such necessity of setting the rpath.
As to the pkgconfig files, gentoo does not use fixed dir the sed expression is:
s|\(^Libs: -L.*\)\($\)|\1 -Wl,-R\$\{libdir\}\2|
so it simply adds -Wl,-R${libdir} , which is standard variable in the pkg-config files and should be set to the correct value from the mozilla default installation process and should correspond to the --with-default-mozilla-five-home settings.
Is it possible/safe to add rpath options to mozilla pkgconfig files?
AFAIK, gcc and ld have mutually incomprehensible option syntax for rpath (gcc cloaks ld's options under -Wl). Is it OK to assume that Libs: is for gcc only?
if you have rpath set libraries it is ok to use the rpath in the pkg-config files, if not it will lead to bugs.
(In reply to comment #16)
> if you have rpath set libraries it is ok to use the rpath in the pkg-config
> files, if not it will lead to bugs.

I see. Let's assume I have (should upload that Mozilla patch here).
What about the format? I realized that libtool accepts both gcc and ld syntax. Since all good boys use libtool, it should be OK to use any form, right?
This patch extends the LIBRUNPATH environment variable kludge, which exists for BSD, to Linux builds. Tangentially, it dispenses with the identical security/coreconf/Linux.*.mk files in favor of the single centralized security/coreconf/Linux.mk, accordingly to a suggestion expressed in security/coreconf/config.mk.
(In reply to comment #9)
> > > Has anyone tested to see what happens when you add -Wl,-rpath,/my/special/dir
> > > to LDFLAGS when running configure?
> 
> Hm, it looks like it works for gtkembedmoz, but not for some of the others:
> # yelp-bin
> /usr/libexec/ld-elf.so.1: Shared object "libnspr4.so" not found, required by
> "libplds4.so"
> (of course yelp has been compiled with -rpath, too)
> 
> It looks like libplds4.so didn't get compiled with -rpath:
> # readelf -a /usr/X11R6/lib/mozilla/libplds4.so | grep PATH
> #
> 
> Or is this expected behaviour?
> OTOH, this build together with tweaking pkg-config was sufficient to make
> 'devhelp' run without a shell-wrapper.
> 
> Now I'm a bit confused. Just for the record, could somebody please point out
> the cons of using -rpath to me? Is there anything else apart from being able to
> choose which set of libs to use through LD_LIBRARY_PATH?
> 

I have an application that attempts to dynamically load libgtkembedmoz at runtime.. simply by changing working directory to the mozilla lib directory and using g_module_open.  This works just fine for several linux distros, but not for Suse 10.0.. giving a not found error.  Can anyone suggest a solution (besides setting LD_LIBRARY_PATH in a wrapper script)?


Mass bug cleanup for Core:Build Config.

If you feel this bug has been closed in error, please re-open with new details.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: