Date: Mon, 03 Mar 2008 12:34:34 +0100 From: Alexander Leidinger <Alexander@Leidinger.net> To: Joe Marcus Clarke <marcus@marcuscom.com> Cc: freebsd-gnome@freebsd.org Subject: Re: Evolution crawls on FreeBSD Message-ID: <20080303123434.cch4vbr34084sg08@webmail.leidinger.net> In-Reply-To: <1204504294.40616.24.camel@shumai.marcuscom.com> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
Quoting Joe Marcus Clarke <marcus@marcuscom.com> (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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080303123434.cch4vbr34084sg08>