Description of problem: Currently, running "xmlrpc-c-config client --libs" outputs "-lxmlrpc_client". With the new DSO changes, apps which used to link correctly don't any more. Version-Release number of selected component (if applicable): xmlrpc-c-devel-1.21.00-1300.1851.fc13.x86_64 How reproducible: Always. Steps to Reproduce: 1. cat > version.c << EOF #include <stdio.h> #include <xmlrpc_client.h> int main(int argc, char **argv) { printf("Version %d.%d.%d.\n", xmlrpc_version_major, xmlrpc_version_minor, xmlrpc_version_point); return 0; } EOF 2. gcc -Wall -o version `xmlrpc-c-config client --cflags` version.c `xmlrpc-c-config client --libs` Actual results: /usr/bin/ld: /tmp/cc5J8U8r.o: undefined reference to symbol 'xmlrpc_version_major' /usr/bin/ld: note: 'xmlrpc_version_major' is defined in DSO /usr/lib64/libxmlrpc.so.3 so try adding it to the linker command line /usr/lib64/libxmlrpc.so.3: could not read symbols: Invalid operation collect2: ld returned 1 exit status Expected results: Success.
mmmh... that's difficultly to solve :( You are using symbols from 'libxmlrpc-c' but the xmlrpc-c-config script does not know this target. I can modify this script to cover typical usecases, but a) what are "typical usecases"? b) this will lead to overlinking when only pure 'client' functionality (e.g. reading of 'xmlrpc_client_version_major') is required.
I'm not sure what is or isn't a typical use case -- this specific example is a contrived one, for simplicity's sake. My actual app is calling functions like xmlrpc_read_bool() when it's parsing results sent back from a server, and I expect that sort of usage is going to be pretty widespread.
I am going to replace the .so libraries with linker scripts which are including other libxmlrpc_c libs with AS_NEEDED() commands. But this might take some time.
should be fixed by http://koji.fedoraproject.org/koji/buildinfo?buildID=156601