On 02/08/2012 11:12 AM, Fabio M. Di Nitto wrote: > On 2/8/2012 2:52 PM, Steven Dake wrote: >> On 02/07/2012 05:43 PM, Angus Salkeld wrote: >>> Hi >>> >>> Here is a good idea IMO. But as-is will require a re-build of all >>> user applications. >>> >>> We currently have lots of inline functions in header files just to be shared >>> between corosync and the libraries. We also have the same functions >>> been implemented in both places. libqb has helped reduce this but the >>> problem still exists. >>> >>> Another unplesent issue is if we need to apply a fix to any of these >>> inline functions the user applications need to be rebuilt. >>> >>> So choose a rebuild now or multiple times down the line. >>> >>> -Angus >>> >>> >>> cc -o tcpg test/testcpg.c -Iinclude/corosync/ -lcpg >>> /usr/bin/ld: /tmp/ccnqIwOB.o: undefined reference to symbol 'cs_strerror' >>> /usr/bin/ld: note: 'cs_strerror' is defined in DSO /usr/lib64/libcorosync_common.so.4 so try adding it to the linker command line >>> /usr/lib64/libcorosync_common.so.4: could not read symbols: Invalid operation >>> collect2: ld returned 1 exit status >>> >>> >> >> Angus, >> >> I know we had talked about a static library and linking that into each >> so. I had some concerns about symbol collisions. I tested that out, >> and it seems to work. I'd prefer that approach to requiring the need of >> a separate -lcorosync_common. I'll send my patch to the list so you can >> see what I did. I'll also send my test program linked against cpg and cmap. > > How do you get symbol collisions? > symbol collision doesn't occur in shared lib. I was thinking it may occur in static .a when compiled with each of the libraries and then linking the libraries into one process, but that isn't the case. > 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. See: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange > 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
