|
Description
Gergan Penkov
2005-07-28 08:13:42 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
Created attachment 64539 [details, diff]
mozilla-rpath.patch
This will set the correct rpaths to the mozilla's libs and the exes
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
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?
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)
Created attachment 64814 [details, diff]
mozilla-firefox-rpath.patch
Absolutely the same patch as mozilla-thunderbird, using the $ORIGIN-tag made it
possible.
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.
Created attachment 64859 [details, diff]
mozilla-thunderbird-rpath.patch
The same $ORIGIN not working for mangle (mangling the $ORIGIN), so fixed path.
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.
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 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.
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.
Created attachment 65890 [details]
mozilla-firefox-1.0.6-r6.ebuild
And this is the full ebuild for mozilla-firefox-1.0.6
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.
Created attachment 65892 [details]
mozilla-1.7.11-r1.ebuild
The full ebuild for mozilla-1.7.11
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)
Created attachment 65911 [details]
mozilla-thunderbird-1.0.6-r5.ebuild
And the full ebuild for the mozilla-thunderbird.
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.
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.
Created attachment 65973 [details]
mozilla-firefox-1.0.6-r6.ebuild
The same not fully qualified name firefox-nspr.pc in the sed
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. 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. 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. 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. I have added myself to the bug upstream and will monitor. Thanks 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. 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. 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. 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? 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
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) I submitted a new bug for the gecko-sdk rpath-patch to Joseph Jezak as you recommended (bug #104273). Looks concluded to me, resolving. |
