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). >>> >> >> I don't want someone that has -cpg in their app to have to put in >> -lcoroxsync_common to get access to the symbols. It used to work >> transparently, but was recently changed in fedora. > > I tested exactly this case in rawhide today and it didn´t show the > problem. Unless they are enforcing it in mock only build and that would > be wrong from the Fedora part since those options should be default > everywhere in a fedora environment. > > Then again, this is upstream and not fedora. > > Fabio mock may not match f16? Not sure, but it does behave this way on my f16 platform. Regards -steve _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
