On 02/08/2012 01:43 AM, 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 This is a very good idea, but I think you get that error because libcpg is not correctly linked with libcorosync_common in the build system. Using your example above, testcpg.c does not use cs_strerror directly. libcpg does. In that case libcpg needs to pull corosync_common. I can see from the patch that you do link libcpg with common, but perhaps it's missing a simple bit somewhere that makes it fail. also well done by updating the .pc files. Either way +1 to rebuild everything now rather than later. Fabio _______________________________________________ discuss mailing list discuss@xxxxxxxxxxxx http://lists.corosync.org/mailman/listinfo/discuss
