On 02/20/2012 01:48 AM, Fabio M. Di Nitto wrote: > 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 :) > I am not hot on shared object, but really have lost interest in this topic. Honza should make the final decision since he will be maintaining what comes out for some time. Regards -steve > Fabio > _______________________________________________ > discuss mailing list > discuss@xxxxxxxxxxxx > http://lists.corosync.org/mailman/listinfo/discuss _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
