On 2/20/2012 5:47 AM, Angus Salkeld wrote: > On 17/02/12 08:22 +1100, Angus Salkeld wrote: >> On 16/02/12 16:04 +0100, Fabio M. Di Nitto wrote: >>> On 2/16/2012 3:58 PM, Vladislav Bogdanov wrote: >>>> 16.02.2012 14:50, Fabio M. Di Nitto wrote: >>>>> On 2/16/2012 12:36 PM, Jan Friesse wrote: >>>>>> Fabio M. Di Nitto napsal(a): >>>>>>> On 2/8/2012 9:41 PM, Steven Dake wrote: >>>>>>>> On 02/08/2012 12:27 PM, Fabio M. Di Nitto wrote: >>>>>>>>> On 2/8/2012 8:19 PM, Steven Dake wrote: >>>>>>>>> >>>>>>>>>>> Assuming you are upgrading from version X to X+1, the symbols >>>>>>>>>>> will >>>>>>>>>>> simply move from static inline to the share object. Specially >>>>>>>>>>> in this >>>>>>>>>>> case where the application is not affected directly. >>>>>>>>>>> >>>>>>>>>>> application -> libfoo (with static inline) >>>>>>>>>>> application -> libfoo -> libcommon >>>>>>>>>>> >>>>>>>>>>> Even in a downgrade case, libcorosync_common would not be >>>>>>>>>>> referenced by >>>>>>>>>>> any of the libraries. >>>>>>>>>>> >>>>>>>>>>> I don´t have a strong opinion here, but I would prefer to >>>>>>>>>>> have it a >>>>>>>>>>> shared lib. We had some nasty issues with static before (ask >>>>>>>>>>> Jan how >>>>>>>>>>> long it took for him to debug that handle_ corruption when >>>>>>>>>>> linking >>>>>>>>>>> static). >>>>>>>>>>> >>>>>> >>>>>> Hey, that handle_ thing was *real* pain. Took like week (40 hours) of >>>>>> extra hard work. >>>>> >>>>> Exactly.... :) >>>>> >>>>> [BIG FAT SNIP] >>>>>>> You also need to take into account that not all distribution ship >>>>>>> all >>>>>>> libraries in one package (corosynclib vs libcpg4 libquorum4). So >>>>>>> it´s >>>>>>> not that uncommon as you might think and it leaves a window open for >>>>>>> lots of headaches. >>>>>>> >>>>>>> You make your call, but static is bad vs a very small pain to get >>>>>>> applications linked correctly (as they should be) and pkg-config >>>>>>> can be >>>>>>> used to ease the pain (tho i am still not sure we should enforce >>>>>>> linking >>>>>>> with -lcorosync_common since not all applications use symbols >>>>>>> from it). >>>>>>> >>>>>> >>>>>> Ok, it looks like I've misunderstood >>>>>> http://fedoraproject.org/wiki/UnderstandingDSOLinkChange. So as >>>>>> long as >>>>>> it works as you said (app using lcpg, but not cs_errorstr DON'Tt >>>>>> need to >>>>>> link with -common), then shared link solution seems to be better. >>>>>> But if >>>>>> it doesn't work (ie. lcpg linked with lcommon, app need to link with >>>>>> both), static approach is better. >>>>> >>>>> I have tested both F16 and rawhide about the same way but by all mean, >>>>> we can give it another test round. >>>>> >>>>>> Also I don't see reason for pkg-config to include -lcommon. >>>>>> >>>>>> So one question is, where made Angus mistake so DSO warning appeared >>>>>> (and whole this thread started)? >>>>> >>>>> I can´t say for sure without doing the exact same build, but with the >>>>> branch he published in topic-commonlib, it was working fine. >>>>> >>>>> He probably forgot to link libcpg with libcorosync_common shared at >>>>> that >>>>> stage of testing. The only way to know would be to see ldd libcpg >>>>> in his >>>>> system. >>>>> >>>>> Angus, is it an option for you to revalidate my testing? It´s no point >>>>> for me to do it all over again. We need a 3rd party to look at it :) >>>> >>>> Sorry for stepping in, but that is absolutely true for new fedora >>>> systems (from that point where indirect linking was prohibited), that >>>> you need to link app against lib *only* if you use symbols from that >>>> lib >>>> directly in app (including calls from inline functions defined in >>>> "foreign" header files, may be that was the reason of that warning?). >>> >>> That´s what my test did show :) but apparently Angus still got somekind >>> of error during his tests. The point remains that I cannot repeat Angus >>> test but he can validate the tests i did :) >>> >>>> You *do not* need to link against the whole stack of libs which are >>>> used >>>> indirectly, but whose symbols you do not reference. >>> >>> Exactly. see previous emails in this thread. >> >> I'll give it a go today and let you know. > > > So the reason my test failed was that I patched testcpg to directly > call one of those error functions. That makes sense given what Fabio > has explained. > > So can we go ahead with the .a -> .so or are we sticking to the static > lib? (I vote for .so). > Just for the record, .so pretty please with a spoon of sugar and love :) Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
