Evolution crawls on FreeBSD

[Alexander Leidinger]

Quoting Joe Marcus Clarke <marcus at marcuscom.com> (from Sun, 02 Mar  
2008 19:31:34 -0500):

Summary: the patch in the PR is not at production quality, I  
understand the portmgr decision, ideally the rejection reason (by Ade  
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:
>>
>> 	http://www.freebsd.org/cgi/query-pr.cgi?pr=104877
>>
>> 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  
patch will not help much (at least it will not directly result in the  
ideal solution). I experimented with a different patch. My patch  
changes libtool directly (I discussed this with the libtool  
maintainers, libtool 1.5 has problems with static linking and maybe  
cross-compiling when this is done, that's the reason why it is not  
enabled by default in Linux, Debian has a patch and enables it itself,  
but this is not sanctioned by the libtool maintainers, libtool 2.0 is  
supposed to solve the problem, my patch to libtool 1.5 should not be  
applied, as it will break libtool in a few cases).

The result of the patch is, that some libs are not added. This is  
good. But a lot of ports (X libs, cairo, pango, gtk, ...) add the libs  
on the link command line, so that those libs get added, even if they  
are dependencies which can be resolved recursively. To solve this, the  
corresponding ports need to be changed. Ideally this should happen  
upstream. pkg-config has support for this (private_libs or something  
like this), but in a lot of packages this is not used yet. The right  
fix for this software is to add the indirect dependencies to those  
private libs stuff in the pkg-config part. When libtool 2.0 hits the  
tree and is adopted, the problem should vanish then (and we could  
switch to explicit package dependencies, it would cut down a lot the  
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  
details regarding the rejection.

Just by looking at the PR (and knowing about the public mails between  
Ade and jylefort) it _looks_ like Ade has no idea what he is talking  
about for this particular patch. If he would have added some more  
words why he thinks that the patch is not ok, then it would look  
differently. So I can understand the reaction of jylefort.

Note, as you can see above, I talked with the libtool maintainers and  
know the drawbacks of the patch in the PR. It can only be applied to  
dynamic libs. Static libs and some cross-compiling situations should  
not be handled with this (personally I would suggest an opt-out knob,  
but as the patch will not be imported...). In general I don't see  
major showstoppers for something like this (if libtool itself is not  
modified), but it will not be as easy as just adding this patch. I  
expect several experimental port builds and adding of e.g. the above  
mentioned opt-out knob to some ports, until the patch is at production  
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.  
Nothing I write above is meant to be rude or force someone to do  
something (just in case someone got up with a bad mood today).

Bye,
Alexander.

-- 
Kiss your keyboard goodbye!

http://www.Leidinger.net    Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org       netchild @ FreeBSD.org  : PGP ID = 72077137