From owner-freebsd-gnome@FreeBSD.ORG Mon Mar 3 11:50:55 2008 Return-Path: Delivered-To: freebsd-gnome@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E7BA4106566B for ; Mon, 3 Mar 2008 11:50:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from redbull.bpaserver.net (redbullneu.bpaserver.net [213.198.78.217]) by mx1.freebsd.org (Postfix) with ESMTP id 76DFB8FC15 for ; Mon, 3 Mar 2008 11:50:55 +0000 (UTC) (envelope-from alexander@leidinger.net) Received: from outgoing.leidinger.net (p54A55014.dip.t-dialin.net [84.165.80.20]) by redbull.bpaserver.net (Postfix) with ESMTP id 6B7E02E1DD; Mon, 3 Mar 2008 12:34:41 +0100 (CET) Received: from webmail.leidinger.net (webmail.leidinger.net [192.168.1.102]) by outgoing.leidinger.net (Postfix) with ESMTP id ACC1B942EB; Mon, 3 Mar 2008 12:34:35 +0100 (CET) Received: (from www@localhost) by webmail.leidinger.net (8.14.2/8.13.8/Submit) id m23BYYwY061540; Mon, 3 Mar 2008 12:34:34 +0100 (CET) (envelope-from Alexander@Leidinger.net) Received: from pslux.cec.eu.int (pslux.cec.eu.int [158.169.9.14]) by webmail.leidinger.net (Horde MIME library) with HTTP; Mon, 03 Mar 2008 12:34:34 +0100 Message-ID: <20080303123434.cch4vbr34084sg08@webmail.leidinger.net> X-Priority: 3 (Normal) Date: Mon, 03 Mar 2008 12:34:34 +0100 From: Alexander Leidinger To: Joe Marcus Clarke References: <20080301181608.5d393e02.ejcerejo@optonline.net> <1204415453.1262.26.camel@shumai.marcuscom.com> <20080301191214.58432ae0.ejcerejo@optonline.net> <1204417247.1262.29.camel@shumai.marcuscom.com> <20080301204637.74cfc75f.ejcerejo@optonline.net> <1204424514.1262.36.camel@shumai.marcuscom.com> <20080303001237.28a45ba9.jylefort@brutele.be> <1204504294.40616.24.camel@shumai.marcuscom.com> In-Reply-To: <1204504294.40616.24.camel@shumai.marcuscom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Internet Messaging Program (IMP) H3 (4.1.5) / FreeBSD-8.0 X-BPAnet-MailScanner-Information: Please contact the ISP for more information X-BPAnet-MailScanner: Found to be clean X-BPAnet-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-13.9, required 6, BAYES_00 -15.00, OPT_OUT 1.00, RDNS_DYNAMIC 0.10) X-BPAnet-MailScanner-From: alexander@leidinger.net X-Spam-Status: No Cc: freebsd-gnome@freebsd.org Subject: Re: Evolution crawls on FreeBSD X-BeenThere: freebsd-gnome@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GNOME for FreeBSD -- porting and maintaining List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2008 11:50:56 -0000 Quoting Joe Marcus Clarke (from Sun, 02 Mar =20 2008 19:31:34 -0500): Summary: the patch in the PR is not at production quality, I =20 understand the portmgr decision, ideally the rejection reason (by Ade =20 and/or portmgr) in the PR should have been more detailed. A long and more detailed answer with improvement suggestions is below... > > On Mon, 2008-03-03 at 00:12 +0100, Jean-Yves Lefort wrote: >> I suspect that the patch in this PR would have greatly helped: >> >> =09http://www.freebsd.org/cgi/query-pr.cgi?pr=3D104877 >> >> Indeed, a casual inspection of libexec/rtdl-elf/rtld.c shows that the >> SO_NEEDED lists (Obj_Entry.needed) are walked recursively. Removing >> the useless entries might therefore have a dramatic impact on >> performance. > > This is what mezz suspected as well, and I believe he will test this. As already told to him today in a private discussion: Adding only this =20 patch will not help much (at least it will not directly result in the =20 ideal solution). I experimented with a different patch. My patch =20 changes libtool directly (I discussed this with the libtool =20 maintainers, libtool 1.5 has problems with static linking and maybe =20 cross-compiling when this is done, that's the reason why it is not =20 enabled by default in Linux, Debian has a patch and enables it itself, =20 but this is not sanctioned by the libtool maintainers, libtool 2.0 is =20 supposed to solve the problem, my patch to libtool 1.5 should not be =20 applied, as it will break libtool in a few cases). The result of the patch is, that some libs are not added. This is =20 good. But a lot of ports (X libs, cairo, pango, gtk, ...) add the libs =20 on the link command line, so that those libs get added, even if they =20 are dependencies which can be resolved recursively. To solve this, the =20 corresponding ports need to be changed. Ideally this should happen =20 upstream. pkg-config has support for this (private_libs or something =20 like this), but in a lot of packages this is not used yet. The right =20 fix for this software is to add the indirect dependencies to those =20 private libs stuff in the pkg-config part. When libtool 2.0 hits the =20 tree and is adopted, the problem should vanish then (and we could =20 switch to explicit package dependencies, it would cut down a lot the =20 number of ports to recompile in some situations). >> Unfortunately, the affected maintainer has closed the PR, mainly >> because he could not understand it. And portmgr has backed the >> maintainer, mainly because of personal friendship. > > We did not side with ade out of friendship. We had to weigh the benefit > of this patch against the benefit of having a dedicated autotools > maintainer. Since autotools is quite complex, but very critical to a > large number of ports, and since we didn't have people lining up to be > autotools maintainers, we opted to respect ade's maintainership of > libtool, and his decision. I don't think you would like it very much if > portmgr told you that you had to commit something to a port that you > maintained. But I don't mind if portmgr ask me in such a situation for more =20 details regarding the rejection. Just by looking at the PR (and knowing about the public mails between =20 Ade and jylefort) it _looks_ like Ade has no idea what he is talking =20 about for this particular patch. If he would have added some more =20 words why he thinks that the patch is not ok, then it would look =20 differently. So I can understand the reaction of jylefort. Note, as you can see above, I talked with the libtool maintainers and =20 know the drawbacks of the patch in the PR. It can only be applied to =20 dynamic libs. Static libs and some cross-compiling situations should =20 not be handled with this (personally I would suggest an opt-out knob, =20 but as the patch will not be imported...). In general I don't see =20 major showstoppers for something like this (if libtool itself is not =20 modified), but it will not be as easy as just adding this patch. I =20 expect several experimental port builds and adding of e.g. the above =20 mentioned opt-out knob to some ports, until the patch is at production =20 quality. > Personally, I like your patch. I was a big supported (and user) of > ltverhack as well. There are quite a few things I would like to see > committed to FreeBSD (e.g. this patch, pthread changes, etc.) but I have > to respect the wishes of the maintainers of those subsystems as I could > not, nor would not be able to, do a better job. I can understand your motivation. I don't object to your decision. =20 Nothing I write above is meant to be rude or force someone to do =20 something (just in case someone got up with a bad mood today). Bye, Alexander. --=20 Kiss your keyboard goodbye! http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID =3D B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID =3D 72077137