Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more

[Alan McKinnon]

On 24/09/2015 20:12, Fernando Rodriguez wrote:
> On Tuesday, August 25, 2015 7:58:44 PM Alan McKinnon wrote:
>> On 25/08/2015 19:43, Fernando Rodriguez wrote:
>>> On Tuesday, August 25, 2015 12:30:09 PM Alan McKinnon wrote:
>>>> On 25/08/2015 04:28, Fernando Rodriguez wrote:
>>>>> On Monday, August 24, 2015 9:31:38 PM Alan McKinnon wrote:
>>>>>> Does anyone have an opinion to offer on bug 501468?
>>>>>>
>>>>>> https://bugs.gentoo.org/show_bug.cgi?id=501468
>>>>>>
>>>>>> It's been annoying me for a week now with this message:
>>>>>>
>>>>>> !!! existing preserved libs:
>>>>>>>>> package: www-client/firefox-40.0.2
>>>>>>  *  - /usr/lib64/firefox/libmozalloc.so
>>>>>>  *      used by /usr/lib64/thunderbird/components/libdbusservice.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>>  *      used by /usr/lib64/thunderbird/components/libmozgnome.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>>  *      used by
>>>>>> /usr/lib64/thunderbird/distribution/extensions/{e2fda1a4-762b-4020-
> b5ad-
>>>>> a41df1933103}/components/libcalbasecomps.so
>>>>>> (mail-client/thunderbird-38.2.0)
>>>>>>  *      used by 4 other files
>>>>>>
>>>>>>
>>>>>> Both Mozilla products ship this file:
>>>>>>
>>>>>> $ locate libmozalloc
>>>>>> /usr/lib64/firefox/libmozalloc.so
>>>>>> /usr/lib64/thunderbird/libmozalloc.so
>>>>>>
>>>>>> and according to preserved libs, thunderbird linked to the firefox copy.
>>>>>> The only offered solution on the bug is to use a MASK variable, which
>>>>>> seems to me an ugly hammer to swat a fly.
>>>>>>
>>>>>> I was wondering if there's a better way been developed in the last
> year.
>>>>>
>>>>> Actually, now I have a general idea of what's going on and that sounds
>>> like an
>>>>> acceptable solution but perhaps I could be better. This is what happens:
>>>>>
>>>>> 1. revdep-rebuild uses ldd to find breakage. It finds breakage in
>>>>> libdbusservice.so because firefox uses tricks to preload the library from
>>> it's
>>>>> directory.
>>>>> 2. revdep-rebuild find that thunderbird provides the library and thinks
> it
>>>>> needs to be rebuild. (And wrongly tells you that firefox links against
> it).
>>>>>
>>>>> A better way would be:
>>>>>
>>>>> 1. same as step 1 above
>>>>> 2. revdep-rebuild checks the package that provides the broken binary (in
>>> this
>>>>> case the firefox package), if this package also provides the missing
>>> library
>>>>> then it's safe to ignore the problem.
>>>>> 3. same as step 2 above.
>>>>>
>>>>> Another solution is to make patch firefox to use RPATH so ldd can find the
>>>>> labraries, this would also make prelink work better with firefox but it's
>>>>> probably not ideal to mantain.
>>>>
>>>>
>>>> that does make sense. In my case, it's not revdep-rebuild causing
>>>> problems, it's the preserved-rebuild message at the end of emerge -v
>>>>
>>>> At this level is there a difference?
>>>
>>> I don't know the details but it seems to me that portage either uses
> revdep-
>>> rebuild to find breakage (without scanning the whole system) before
> deleting
>>> the old libs for good or duplicates some of it's logic. Come to think of
> it,
>>> the SEARCH_DIR_MASK may not be ideal because if I understand what it does
>>> correctly then real breakage in firefox won't be detected.
>>>
>>
>> My thought too. To me, SEARCH_DIR_MASK is fine for things like
>> /opt/skype because it's binary and either works or it doesn't, and when
>> it doesn't there's not much I can do about it.
>>
>> It may be the least sucky of all available solutions, but it's still
>> swatting a fly with a hammer
>
> I may have found  a better solution. I patched my ebuild [1], but you should
> be able to just add the following to LDFLAGS in /etc/portage/env:
>
> Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-
> rpath,/usr/lib/browser/components
>
> If you do the same for thunderbird (adjusting the library dirs) you should be
> able to remove the SEARCH_DIR_MASK. I also patched the ebuild not to install
> that file on /etc/revdep-rebuild. If you use prelink firefox will start a little
> faster on a slow machine.
>
> You can tell if it worked by running:
>
> # ldd /usr/lib/firefox/components/libdbusservice.so | grep libxul
>
> It should output something like:
>
> libxul.so => /usr/lib64/firefox/libxul.so (0x00007fcc22eb8000)
>
> instead of:
>
> libxul.so => not found
>
>
> [1] https://github.com/fernando-rodriguez/portage-overlay/blob/master/www-client/firefox/firefox-41.0.ebuild#L254
>


Thanks, using env/ files worked a charm. @preserved-rebuild is no longer
confused.

For the record and the archives, I think you hand-typed the env strings
and got the inevitable typos. Here's what the files must be for anyone
else having the same problem. Contents on one line (mailer line wrapping
...):

# cat /etc/portage/env/mail-client/thunderbird-38.2.0
LDFLAGS="${LDFLAGS}
-Wl,-rpath,/usr/lib/thunderbird,-rpath,/usr/lib/thunderbird/components"
# cat /etc/portage/env/www-client/firefox-41.0
LDFLAGS="${LDFLAGS}
-Wl,-rpath,/usr/lib/firefox,-rpath,/usr/lib/firefox/components,-rpath,/usr/lib/firefox/browser/components"


-- 
Alan McKinnon
alan.mckinnon@×××××.com