The output formatting could be better, this output says that Code: (g_strrstr(blacklist, wname) && !(c->portait_supported || c->portait_requested))==1 but apparently the second part of this check sometimes is true, sometimes is false, which makes whole result of blacklist check to be sometimes true and sometimes false... either c->portrait_supported or c->portrait_requested gets changed during program runtime, I will debug further to check how this happens.
(g_strrstr(blacklist, wname) && !(c->portait_supported || c->portait_requested))==1
Is it libaegis-crypto or libaegis-crypto1? In Meego, you have both libcrypto (version 0.9.8) and libcrypto1 (I guess it may be the same library but it has version 1.0.0), see the site which compares Fremantle to Harmattan I linked earlier. If libaegis-crypto1 is linked against libcrypto1 (judging by the name I suppose it can be), you should first backport libcrypto1 and link it against it, not against Fremantle's libcrypto (0.9.8) - did you do that? (or is it not linked against libcrypto at all?)
Edit 1: And, again about that site - it is created by a company which makes quite detailed comparisons. You can see that even when there is "compatible" result for a library, they sometimes put notes in further columns (when e.g. Harmattan version exports more functions, has warnings, etc.), so I think we may trust them when they say "compatible" or "incompatible".
Edit 2: They even compared libc ! you can see there are 8 problems and 25 warnings in columns "Backward binary compatibility problems"! If we fix them, stock calendar app should work with newer libc