Date: Tue, 04 Mar 2008 12:27:08 -0500 From: Joe Marcus Clarke <marcus@freebsd.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: freebsd-gnome@freebsd.org Subject: Re: Evolution crawls on FreeBSD Message-ID: <47CD866C.8020909@freebsd.org> In-Reply-To: <20080304104855.8dk4kbnbac4g4kc4@webmail.leidinger.net> References: <20080301181608.5d393e02.ejcerejo@optonline.net> <1204424514.1262.36.camel@shumai.marcuscom.com> <20080303001237.28a45ba9.jylefort@brutele.be> <200803040842.47946.roy@marples.name> <20080304104855.8dk4kbnbac4g4kc4@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexander Leidinger wrote:
> Quoting Roy Marles <roy@marples.name> (from Tue, 4 Mar 2008 08:42:47
> +0000):
>
>> On Sunday 02 March 2008 23:12:37 Jean-Yves Lefort wrote:
>>> 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.
>>
>> One thing that may help here is allowing the use of cutsom LDFLAGS -
>> namely -Wl,--as-needed. This removes SO_NEEDED references when the
>> library
>> really isn't needed. For a more indepth discussion on the benefits of
>> this,
>
> This sounds really interesting! We would have to check which compiler
> versions understand this flag. And it is a nin-intrusive change to the
> autotools chain. And making ports honor LDFLAGS (like they do with
> CFLAGS) is a good ideas IMO.
>
>> read this article [1]. I had a quick look at ports, but it doesn't
>> seem to
>> honor LDFLAGS in any port. Sadly most of the world needs to be
>> compiled with
>> this LDFLAG for it to really work, so I didn't look much futher.
>> FreeBSD base
>> system compiles fine with it though :)
>
> Oh, if the gnome maintained ports would honor LDFLAGS, it would already
> be a big deal (and probably solve the issue with evolution).
All GNOME ports honor LDFLAGS. We pass custom LDFLAGS via CONFIGURE_ENV
to every port (i.e. to add -L${LOCALBASE}/lib). This would be trivial
to test. As for the linker patch, I see the same slowish startup on 7.X
and 8.X, so I do not think it will help. That said, if you are using
the FBSD linker in G/FBSD, and you're not seeing this problem, there
must be something else that's keep Evo in the linker for so long. Thus
far, I haven't heard any default Gentoo option that may account for
this. Perhaps you have some other libtool patches or other custom
patches not in any version of FBSD...?
Joe
>
> Thanks for info,
> Alexander.
>
--
Joe Marcus Clarke
FreeBSD GNOME Team :: gnome@FreeBSD.org
FreeNode / #freebsd-gnome
http://www.FreeBSD.org/gnome
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47CD866C.8020909>