GNOME Bugzilla – Bug 528986
need runtime detection of new libical memory handling
Last modified: 2008-05-06 20:31:10 UTC
I definitely need some way to detect at runtime whether the patch for bug #516408 has been applied to the libraries that SyncEvolution uses. Please apply the patches that I proposed in that bug discussion to the 22.x branch and trunk, or suggest and implement some other means of achieving the runtime detection. Thanks, Patrick
Created attachment 109569 [details] [review] let's clients determine at runtime whether they have to free memory Here's the patch which adds a global variable "ical_memfixes" which (similar to ICAL_MEMFIXES at compile time) can be checked to determine whether the current library expects clients to free memory.
Created attachment 109570 [details] demonstrates how to check at compile and runtime whether memory must be freed Compile with cc -Wl,--as-needed `pkg-config --cflags libecal-1.2` ecaltest.c -o ecaltest `pkg-config --libs libecal-1.2` I compiled against Evolution 2.10.3. It ran correctly with that and with libecal from trunk (without the soname change) - correctly in the sense that it detected whether it had to free memory and only did that when required. When compiled against trunk it detects the preprocessor symbol and always frees memory. Due to the soname change it will refuse to run with older libecal, as intended.
Patrick, is there any new/deleted function/globals between 2.12 and 2.22. That may also solve the problem.
The only difference in the list of exported symbols is the removal of "mime_lex". If I were to depend on that minor difference, then I run the risk of incorrectly freeing memory when (for whatever reason) that symbol gets added again. That doesn't look right to me. What's so bad about marking the ical mem patch by adding a dedicated global symbol? The check in client code for that symbol is platform specific, but adding the symbol is perfectly okay also on platforms where the check doesn't work. Bye, Patrick
Patrick, it is nothing bad or something like that. Just I was looking other better possibilities. I'm fine with going your way. I will just wait for chen to see if he has any concerns and then commit it, if he is fine. (Chen should be back to office on Monday)
Patrick, as michael had already commented on the patch at bug 516408, its a hack. Anyways I don mind in having the patch which adds the variable in libical. Please mention its a hack in the comment before committing.
> Patrick, as michael had already commented on the patch at bug 516408, its a > hack. And so would be making assumptions about which libecal versions have the patch, if the version could be checked at runtime, or using unrelated changes to libecal to detect the patch... using a dedicated marker variable is actually the smallest evil. > Anyways I don mind in having the patch which adds the variable in > libical. Please mention its a hack in the comment before committing. I don't have commit rights for the repository. Can someone apply for me on trunk and the stable branch, please? Alternatively, if you think that I should better commit myself, then please grant the necessary privileges and I'll do it myself.
Committed to gnome-2-22 and trunk.