Re: [Evolution-hackers] detecting new ical memory tracking

2008-05-06 Thread Patrick Ohly
On Mon, 2008-04-21 at 11:13 +0530, Srinivasa Ragavan wrote: Your deal is to add a new global variable, and dlopen it to find if it is new e-d-s or not. Is there something new we already added in 2.22.x that you can find to dlopen, instead of adding a new ? As discussed in the bug tracker,

Re: [Evolution-hackers] detecting new ical memory tracking

2008-04-20 Thread Patrick Ohly
Hello, this issue is getting urgent and needs to be solved, otherwise I cannot get rid of the memory leaks which currently break the nightly testing with trunk. I have created http://bugzilla.gnome.org/show_bug.cgi?id=528986 with the appeal to add the ical_memfixes variable (patch attached to

[Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Patrick Ohly
Hello, I now have the situation that I feared in issue #516408: SyncEvolution trunk uses libical calls where the returned string must be freed when SyncEvolution runs with Evolution 2.22 and must not be freed when run with older Evolution releases. My plan still is to only provide only one binary

Re: [Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Matthew Barnes
On Tue, 2008-04-08 at 21:42 +0200, Patrick Ohly wrote: Introducing the code rewrite suggested by Michael is impossible. Can I have the less intrusive patch included on trunk and the stable branch, please? Or is there some other version number which can be queried at runtime? I'd rather not

Re: [Evolution-hackers] detecting new ical memory tracking

2008-04-08 Thread Patrick Ohly
On Di, 2008-04-08 at 18:29 -0400, Matthew Barnes wrote: More broadly, we should add some versioning macros and symbols to libedataserver similar to [1], so Patrick could do something like: #if EDS_CHECK_VERSION(2,22,0) ... free libical strings ... #endif Would that address your