From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id ACE2D13881E for ; Fri, 25 Sep 2015 15:31:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id EC02621C01B; Fri, 25 Sep 2015 15:31:09 +0000 (UTC) Received: from mail-wi0-f182.google.com (mail-wi0-f182.google.com [209.85.212.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id BD1A721C007 for ; Fri, 25 Sep 2015 15:31:08 +0000 (UTC) Received: by wicge5 with SMTP id ge5so25870215wic.0 for ; Fri, 25 Sep 2015 08:31:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=T7/OonsCUlpnzi7lwnx9XzGm9DJEk7MidKin6jJ9UFw=; b=vo5sdnMeLGrW2cjzWZS0BHYzLl6AczvlcwSp4qGgBj+sfh7qAw11UCFJjgsuwxbs0i gJx3UE2jK2P46ySmRXXRrCbR+CW+qm30ROElaRRSqgklyyj/HAqVP8xkkCEKhUNlP4Jt XFqe1JZ1LkvgZj1o5AHobxl68N9x1Y7AyTPQtIauDTcNapRIlzaEL/IjIRi/mGbO6c7Q 5hFjUYtFx//Kqyf0cZEUUCdYaV8DKZpSKUK1LhvISWpXucjhIzFaZGf8FdyXlVszEEKq +QwCJ4dCKkD/DLLWhJiw5Z0NGNgJzZRxTbIz7LurPOn0/q4NzBaznvLK62T9uCnpUN6u ky9g== X-Received: by 10.180.87.74 with SMTP id v10mr3916043wiz.66.1443195067548; Fri, 25 Sep 2015 08:31:07 -0700 (PDT) Received: from [172.20.0.41] (105-237-149-222.access.mtnbusiness.co.za. [105.237.149.222]) by smtp.googlemail.com with ESMTPSA id pg5sm3881488wjb.21.2015.09.25.08.31.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 25 Sep 2015 08:31:06 -0700 (PDT) Subject: Re: [gentoo-user] Endless preserved-rebuild loop, libmozalloc & more To: gentoo-user@lists.gentoo.org References: <55DB711A.5080105@gmail.com> <55DCACD4.9000904@gmail.com> From: Alan McKinnon Message-ID: <560568A1.4000109@gmail.com> Date: Fri, 25 Sep 2015 17:30:41 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Archives-Salt: 4a804ba2-d746-472f-a38f-99f18b581c69 X-Archives-Hash: 65fc088f0dcaae372dd733c6a082f8ad 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@gmail.com