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?). You *do not* need to link against the whole stack of libs which are used indirectly, but whose symbols you do not reference. Verified. Best, Vladislav _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
