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