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. Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
