Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bugzilla DB migration completed. Please report issues to Infra team via email via infra@gentoo.org or IRC

Bug 100597

Summary: The mozilla family of source builds, the ldpath and some problems
Product: Gentoo Linux Reporter: Gergan Penkov <gpp666_999>
Component: New packagesAssignee: Mozilla Gentoo Team <mozilla>
Status: RESOLVED FIXED    
Severity: normal Keywords: Inclusion
Priority: High    
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Bug Depends on: 100718, 100721    
Bug Blocks: 100809, 102487, 102490, 102500, 102661    
Attachments: mozilla-thunderbird-rpath.patch
mozilla-rpath.patch
mozilla-firefox-rpath.patch
gecko-sdk-rpath.patch
mozilla-thunderbird-rpath.patch
mozilla-firefox-rpath.patch
mozilla-firefox-rpath.patch
mozilla-thunderbird-rpath.patch
mozilla-rpath.patch
mozilla-rpath-1.patch
mozilla-firefox-1.0.6-r5.ebuild.diff
mozilla-firefox-1.0.6-r6.ebuild
mozilla-1.7.11.ebuild.diff
mozilla-1.7.11-r1.ebuild
mozilla-thunderbird-1.0.6-r4.ebuild.diff
mozilla-thunderbird-1.0.6-r5.ebuild
mozilla-1.7.11-r1.ebuild
mozilla-1.7.11-r1.ebuild
mozilla-firefox-1.0.6-r6.ebuild

Description Gergan Penkov 2005-07-28 08:13:42 UTC
Here are the problems:

1) the new mozilla-1.7.10-r2 and mozilla-firefox-1.0.6-r3 are missing the link
to /usr/lib/nsbrowser/plugins and are installing correspondingly only the
libnullplugin.so in own plugins directory, which is not needed and the plugin
probably must be installed to /usr/lib/nsbrowser/plugins, only if no plugins are
to be found there or the directory does not exist. (the current behaviour breaks
most notably galeon and epiphany see bug 100008)

2)the /etc/env.d-files for mozilla and mozilla-firefox are exporting ldpath and
other variables, which soils the ldpath and the environment, that's why they
should be completely removed. Moreover it is a thing which is prone to bugs,
because it makes the libraries available twice and could lead to problems with
incorect resolution of other libraries linking to them.
 - solution to this is setting the rpath and I will commit patches for mozilla,
mozilla-firefox and mozilla-thunderd, which will apply the rpath/runpath dynamic
tags to them
 - there are some other advantages to this, after using this patches and
patching /usr/libexec/mozilla-launcher, and removing the ldpath-exports I have
the following results:
 strace -F -f -eopen mozilla 2&> mozilla_with_ldpath.log
and after patching /usr/libexec/mozilla-launcher and removing the ld-export
 strace -F -f -eopen mozilla 2&> mozilla_without_ldpath.log

these are the results
 cat mozilla_with_ldpath.log |grep "(No such"|wc
    419    5086   44299
 cat mozilla_without_ldpath.log |grep "(No such"|wc
    165    1962   18320

so there are 3 time less failed-open-file-attempts, which should hint a faster
start time (because of not searching for standard libraries in mozilla-specific
directories).

3) /usr/libexec/mozilla-launcher (ver. 1.44) is setting the
environment-variables to the old paths:
export MOZILLA_FIVE_HOME=${MOZILLA_LIBDIR:-"/usr/lib/MozillaFirefox"}
export MOZILLA_FIVE_HOME=${MOZILLA_LIBDIR:-"/usr/lib/MozillaThunderbird"}
there is no more executables in MozillaFirefox MozillaThunderbird, and the
correct directories are mozilla-firefox and mozilla-thunderbird and after all,
why are the old directories not completely removed?

Some remarks for the patches, there will be broken libraries, but this could be
probably easily repaired, on my computer these are:
1. epiphany-extensions-1.6.4, compiles fine but not set the rpaths, this
probably should be send upstream, because epiphany is doing allright in this
situation (compiles and sets the rpaths correct and runs)
2. devhelp-0.10 compiles fine, but does not set the rpath of
/usr/lib/libdevhelp-1.so 
3. eclipse-3.0.2, in
/usr/lib/eclipse-3/plugins/org.eclipse.swt.gtk_3.0.2/os/linux/x86/libswt-mozilla-gtk-3064.so
Comment 1 Gergan Penkov 2005-07-28 08:16:19 UTC
Created attachment 64538 [details, diff]
mozilla-thunderbird-rpath.patch

this patch will set the correct rpath/runpath dtags for the executables and the
libraries of mozilla-thunderbird-1.0.6, making it possible for them to run
without the need of adding paths to the linker
Comment 2 Gergan Penkov 2005-07-28 08:17:46 UTC
Created attachment 64539 [details, diff]
mozilla-rpath.patch

This will set the correct rpaths to the  mozilla's libs and the exes
Comment 3 Gergan Penkov 2005-07-28 08:19:28 UTC
Created attachment 64540 [details, diff]
mozilla-firefox-rpath.patch

this will set the rpaths/runpaths of mozilla-firefox's libs and exes, which
will make it possible for them to run without ldpath-tinkering
Comment 4 Gergan Penkov 2005-07-29 20:59:40 UTC
Created attachment 64700 [details, diff]
gecko-sdk-rpath.patch

This is a patch, which will set rpath/runpath of the executables/libraries in
gecko-sdk in order to resolve them correctly to themselves and not to
/usr/lib/nspr/ set of libraries, which is the current situation. 
For example mplayerplug-in link to gecko-sdk at compile time and after that at
run-time resolves to the libraries in /usr/lib/nspr/ (could be tested with ldd)
probably leading to bugs and crashes, although even if it would have made the
linking correct, the libraries in gecko-sdk would have resolved their
dependacies to /usr/lib/nspr/  (again it could be tested with ldd). 
Which could lead to the question is nspr or gecko-sdk superfluous?
Comment 5 Gergan Penkov 2005-07-31 13:15:10 UTC
Created attachment 64813 [details, diff]
mozilla-thunderbird-rpath.patch

This will set the rpath/runpath to some libraries, which missed it (nspr, nss)
and all now are using the $ORIGIN tag. Moving the libraries and binaries should
be no problem. (mozilla-thunderbird)
Comment 6 Gergan Penkov 2005-07-31 13:17:29 UTC
Created attachment 64814 [details, diff]
mozilla-firefox-rpath.patch

Absolutely the same patch as mozilla-thunderbird, using the $ORIGIN-tag made it
possible.
Comment 7 Gergan Penkov 2005-08-01 03:40:26 UTC
Created attachment 64858 [details, diff]
mozilla-firefox-rpath.patch

It seems, that the $ORIGIN will not work. The Makefiles are such a mess, in
particular nss, nspr - seems they are not ported.
Comment 8 Gergan Penkov 2005-08-01 03:44:49 UTC
Created attachment 64859 [details, diff]
mozilla-thunderbird-rpath.patch

The same $ORIGIN not working for mangle (mangling the $ORIGIN), so fixed path.
Comment 9 Gergan Penkov 2005-08-01 03:52:40 UTC
Created attachment 64860 [details, diff]
mozilla-rpath.patch

With all the four-ebuilds (mozilla, mozilla-firefox, mozilla-thunderbird,
gecko-sdk) will resolve only to its own libraries (including nss, nspr ones). 
It's interesting that only evolution-suite and the gnome clock-applet are
linking to nss/nspr-libraries.
Comment 10 Aron Griffis (RETIRED) gentoo-dev 2005-08-02 08:14:58 UTC
Thanks, these patches look great.

Regarding the nsplugins stuff, I believe that's fixed in the latest ~arch and
package.masked ebuilds, available this morning.  To test them, you'll need to do:

echo =www-client/mozilla-1.7.10-r3 >> /etc/portage/package.unmask
echo =www-client/mozilla-firefox-1.0.6-r4 >> /etc/portage/package.unmask
echo =mail-client/mozilla-thunderbird-1.0.6-r4 >> /etc/portage/package.unmask

echo www-client/mozilla ~x86 >> /etc/portage/package.keywords
echo www-client/mozilla-firefox ~x86 >> /etc/portage/package.keywords
echo mail-client/mozilla-thunderbird ~x86 >> /etc/portage/package.keywords
Comment 11 Gergan Penkov 2005-08-13 20:11:43 UTC
Created attachment 65888 [details, diff]
mozilla-rpath-1.patch

This patch (based on the nsplugins trick), should make possible uniformly
patching mozilla, mozilla-firefox and probably mozilla-thunderbird and setting
the rpath in system independant way.
Comment 12 Gergan Penkov 2005-08-13 20:18:55 UTC
Created attachment 65889 [details, diff]
mozilla-firefox-1.0.6-r5.ebuild.diff

This is the diff to the current mozilla-firefox-1.0.6-r5.ebuild. It will
compile all libraries with the corresponding rpath, will install (with ssl
use-flag) nspr and nss libs, archives and includes (needed to build evolution
and evolution-data-server), fixes a bug in the nspr pkg-config file and adds a
-Wl,-R${libdir} flag to all of them. It does not install the binaries from
nss-suite (in /usr/bin), which collide with mozillas and are not needed anyway.
Comment 13 Gergan Penkov 2005-08-13 20:21:13 UTC
Created attachment 65890 [details]
mozilla-firefox-1.0.6-r6.ebuild

And this is the full ebuild for mozilla-firefox-1.0.6
Comment 14 Gergan Penkov 2005-08-13 20:30:19 UTC
Created attachment 65891 [details, diff]
mozilla-1.7.11.ebuild.diff

Patch to mozilla-1.7.11.ebuild, building with rpath-tag set, fix of
mozilla-nspr.pc pkg-config file, adding -Wl,-R${libdir} to the rest of them.
Uses the same mozilla-rpath-1.patch and should use the correct lib-dir.
Comment 15 Gergan Penkov 2005-08-13 20:32:43 UTC
Created attachment 65892 [details]
mozilla-1.7.11-r1.ebuild

The full ebuild for mozilla-1.7.11
Comment 16 Gergan Penkov 2005-08-14 05:37:42 UTC
Created attachment 65910 [details, diff]
mozilla-thunderbird-1.0.6-r4.ebuild.diff

Diff to the current mozilla-thunderbird ebuild, using the uniform patch
(mozilla-rpath-1.patch)
Comment 17 Gergan Penkov 2005-08-14 05:40:20 UTC
Created attachment 65911 [details]
mozilla-thunderbird-1.0.6-r5.ebuild

And the full ebuild for the mozilla-thunderbird.
Comment 18 Gergan Penkov 2005-08-14 14:11:46 UTC
Created attachment 65969 [details]
mozilla-1.7.11-r1.ebuild

There were some bugs - the patch name was not correct and the sed patching the
mozilla-nspr.pc was not on fully qualified name - and because of this was
failing.
Comment 19 Gergan Penkov 2005-08-14 14:13:55 UTC
Created attachment 65970 [details]
mozilla-1.7.11-r1.ebuild

There were some bugs - the patch name was not correct and the sed patching the
mozilla-nspr.pc was not on fully qualified name - and because of this was
failing.
Comment 20 Gergan Penkov 2005-08-14 14:19:11 UTC
Created attachment 65973 [details]
mozilla-firefox-1.0.6-r6.ebuild

The same not fully qualified name firefox-nspr.pc in the sed
Comment 21 Jory A. Pratt 2005-08-14 14:33:45 UTC
If upstream decided is is the right thing to do I would add it but until then I
do not see a reason. Anyone else on mozilla herd want to add anything on this
should do so, Gergan please send this upstream.
Comment 22 Gergan Penkov 2005-08-14 14:40:57 UTC
I don't think the upstream will have any interest, the problems are in the
distributions (bsd for example always use the rpaths). 
Now we here have possibilities to emerge different versions (or similar
packages) and this only means, that the users will suffer from borked run-time
linkage and gentoo should do the thing - it is better alternative to using
ldpath for the packages, which depend on mozilla, firefox, gecko-sdk and pray
for the best.
Comment 23 Jory A. Pratt 2005-08-14 15:57:38 UTC
I am gonna go ahead and test firefox right now as far as them ending up in the
tree simple answer is not yet ... reason I want more input from mozilla herd so
I am not the only included in such a drastic decision.
Comment 24 Gergan Penkov 2005-08-14 16:26:54 UTC
I have posted a bug on mozilla
https://bugzilla.mozilla.org/show_bug.cgi?id=304655 but I don't know what the
result of this would be. It is the normal thing to do java makes it, they make
it for opensolaris (i have seen resolved bug report for nss and nspr). 
It is the only reasonable resolution to the run-time linking problems if you
have more than one library providing the same services.
Comment 25 Jory A. Pratt 2005-08-14 20:39:31 UTC
I have added myself to the bug upstream and will monitor. Thanks
Comment 26 Jory A. Pratt 2005-08-15 13:53:57 UTC
Gergan you will be happy to know we are adding the rpath right now to the tree.
It is gonna be p.mask for testing but it is moving to tree. firefox and
thunderbird are commited already and I will work on committing mozilla as soon
as possible.
Comment 27 Gergan Penkov 2005-08-15 14:21:49 UTC
Thank you very much.
It's a good thing, that we will be probably the first linux-distro, which will
try to resolve the mozilla-linking-nightmare and bring more stability (hopefully).
Thank you for your support and for your fast responses.
Comment 28 Jory A. Pratt 2005-08-15 21:50:43 UTC
I have finally add mozilla-1.7.11-r2 to the tree, yes p.masked. far as gecko-sdk
goes that should be its own bug as we are not responsible for the package.

 cat /usr/portage/net-libs/gecko-sdk/metadata.xml 
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd">
<pkgmetadata>
<herd>mozilla</herd>
<maintainer>
  <email>josejx@gentoo.org</email>
  <name>Joseph Jezak</name>
</maintainer>
</pkgmetadata>

If you would open a new bug on it and assign to josejx@gentoo.org and then we
can close this completely. Thanks for the patch and all you work on the ebuild.
Comment 29 Gergan Penkov 2005-08-16 16:59:19 UTC
I'll file a bug report for gecko-sdk. I've set a thread on gentoo-forums
http://forums.gentoo.org/viewtopic-t-370844.html for testing the ebuilds and the
possibilities they give. 
There is one small thing, which I've missed - patch the mozilla-config and
firefox-config files. I don't know if any package uses them, but for completness
sake, it should look sth like this:
 # Fix firefox-config and install it
        sed -i -e "s|/usr/lib/firefox-${PV}|${MOZILLA_FIVE_HOME}|g
                s|/usr/include/firefox-${PV}|${MOZILLA_FIVE_HOME}/include|g
+               s|\(echo -L.*\)\($\)|\1 -Wl,-R${MOZILLA_FIVE_HOME}\2" \
                ${S}/build/unix/firefox-config

I thank you one more time for all the time spent on my bug and I think you could
close the bug. Or should I make it?
Comment 30 Walter Meinl 2005-08-18 12:31:47 UTC
Gergan,
shouldn't your last fix for firefox-config not read
  # Fix firefox-config and install it
        sed -i -e "s|/usr/lib/firefox-${PV}|${MOZILLA_FIVE_HOME}|g
                s|/usr/include/firefox-${PV}|${MOZILLA_FIVE_HOME}/include|g
+               s|\(echo -L.*\)\($\)|\1 -Wl,-R${MOZILLA_FIVE_HOME}\2|" \
                ${S}/build/unix/firefox-config
When I build firefox-1.0.6-r6 as its now in portage, firefox-config doesn't
change at all (firefox-1.0.6 references are not exchanged). When I add the "|"
at the end of the changed line it works
Cheers
Comment 31 Gergan Penkov 2005-08-18 12:42:35 UTC
yes of course, I've forgot the pipe :) It should be as you suggested it, I
didn't really try it, so it's simply a typo, sorry. (But as I said I didn't find
untill now packages, which use it)
Comment 32 Gergan Penkov 2005-08-30 08:41:15 UTC
I submitted a new bug for the gecko-sdk rpath-patch to Joseph Jezak as you
recommended (bug #104273).
Comment 33 Christian Marie (RETIRED) gentoo-dev 2006-12-20 22:01:02 UTC
Looks concluded to me, resolving.