Gentoo Archives: gentoo-user

From: Fernando Rodriguez <frodriguez.developer@×××××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more
Date: Thu, 24 Sep 2015 18:13:39
Message-Id: BLU436-SMTP130E425421DC1B6732B43C38D430@phx.gbl
In Reply to: Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more by Alan McKinnon
1 On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
2 > On 25/08/2015 19:43, Fernando Rodriguez wrote:
3 > > On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
4 > >> On 25/08/2015 04:28, Fernando Rodriguez wrote:
5 > >>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
6 > >>>> Does anyone have an opinion to offer on bug 501468?
7 > >>>>
8 > >>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
9 > >>>>
10 > >>>> It's been annoying me for a week now with this message:
11 > >>>>
12 > >>>> !!! existing preserved libs:
13 > >>>>>>> package: www-client/firefox-40.0.2
14 > >>>> * - /usr/lib64/firefox/libmozalloc.so
15 > >>>> * used by /usr/lib64/thunderbird/components/libdbusservice.so
16 > >>>> (mail-client/thunderbird-38.2.0)
17 > >>>> * used by /usr/lib64/thunderbird/components/libmozgnome.so
18 > >>>> (mail-client/thunderbird-38.2.0)
19 > >>>> * used by
20 > >>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
21 b5ad-
22 > >>> a41df1933103}/components/libcalbasecomps.so
23 > >>>> (mail-client/thunderbird-38.2.0)
24 > >>>> * used by 4 other files
25 > >>>>
26 > >>>>
27 > >>>> Both Mozilla products ship this file:
28 > >>>>
29 > >>>> $ locate libmozalloc
30 > >>>> /usr/lib64/firefox/libmozalloc.so
31 > >>>> /usr/lib64/thunderbird/libmozalloc.so
32 > >>>>
33 > >>>> and according to preserved libs, thunderbird linked to the firefox copy.
34 > >>>> The only offered solution on the bug is to use a MASK variable, which
35 > >>>> seems to me an ugly hammer to swat a fly.
36 > >>>>
37 > >>>> I was wondering if there's a better way been developed in the last
38 year.
39 > >>>
40 > >>> Actually, now I have a general idea of what's going on and that sounds
41 > > like an
42 > >>> acceptable solution but perhaps I could be better. This is what happens:
43 > >>>
44 > >>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
45 > >>> libdbusservice.so because firefox uses tricks to preload the library from
46 > > it's
47 > >>> directory.
48 > >>> 2. revdep-rebuild find that thunderbird provides the library and thinks
49 it
50 > >>> needs to be rebuild. (And wrongly tells you that firefox links against
51 it).
52 > >>>
53 > >>> A better way would be:
54 > >>>
55 > >>> 1. same as step 1 above
56 > >>> 2. revdep-rebuild checks the package that provides the broken binary (in
57 > > this
58 > >>> case the firefox package), if this package also provides the missing
59 > > library
60 > >>> then it's safe to ignore the problem.
61 > >>> 3. same as step 2 above.
62 > >>>
63 > >>> Another solution is to make patch firefox to use RPATH so ldd can find the
64 > >>> labraries, this would also make prelink work better with firefox but it's
65 > >>> probably not ideal to mantain.
66 > >>
67 > >>
68 > >> that does make sense. In my case, it's not revdep-rebuild causing
69 > >> problems, it's the preserved-rebuild message at the end of emerge -v
70 > >>
71 > >> At this level is there a difference?
72 > >
73 > > I don't know the details but it seems to me that portage either uses
74 revdep-
75 > > rebuild to find breakage (without scanning the whole system) before
76 deleting
77 > > the old libs for good or duplicates some of it's logic. Come to think of
78 it,
79 > > the SEARCH_DIR_MASK may not be ideal because if I understand what it does
80 > > correctly then real breakage in firefox won't be detected.
81 > >
82 >
83 > My thought too. To me, SEARCH_DIR_MASK is fine for things like
84 > /opt/skype because it's binary and either works or it doesn't, and when
85 > it doesn't there's not much I can do about it.
86 >
87 > It may be the least sucky of all available solutions, but it's still
88 > swatting a fly with a hammer
89
90 I may have found a better solution. I patched my ebuild [1], but you should
91 be able to just add the following to LDFLAGS in /etc/portage/env:
92
93 Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-
94 rpath,/usr/lib/browser/components
95
96 If you do the same for thunderbird (adjusting the library dirs) you should be
97 able to remove the SEARCH_DIR_MASK. I also patched the ebuild not to install
98 that file on /etc/revdep-rebuild. If you use prelink firefox will start a little
99 faster on a slow machine.
100
101 You can tell if it worked by running:
102
103 # ldd /usr/lib/firefox/components/libdbusservice.so | grep libxul
104
105 It should output something like:
106
107 libxul.so => /usr/lib64/firefox/libxul.so (0x00007fcc22eb8000)
108
109 instead of:
110
111 libxul.so => not found
112
113
114 [1] https://github.com/fernando-rodriguez/portage-overlay/blob/master/www-client/firefox/firefox-41.0.ebuild#L254
115 --
116 Fernando Rodriguez

Replies

Subject Author
Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more Alan McKinnon <alan.mckinnon@×××××.com>