On 08/01/2013 05:48 AM, Eric Blake wrote:
When compiling qemuagenttest, a link error occurs like: ./.libs/libqemumonitortestutils.a(qemumonitortestutils.o): In function `qemuMonitorTestFree': libvirt/tests/qemumonitortestutils.c:346: undefined reference to `qemuMonitorClose' ./.libs/libqemumonitortestutils.a(qemumonitortestutils.o): In function `qemuMonitorTestNew': libvirt/tests/qemumonitortestutils.c:870: undefined reference to `qemuMonitorOpen' collect2: error: ld returned 1 exit status
What platform was this on? Some distros are set up to be tolerant of lazy resolution, which masks issues like this (hence, I'm _not_ seeing this error on Fedora).
Actually I am using fedora 19 too. And the toolchain is: gcc-4.8.1-1.fc19.x86_64 libtool-2.4.2-16.fc19.x86_64
And I checked this error, it caused by the position of libqemumonitortestutils.a in gcc arguments.
If libqemumonitortestutils.a before libvirt_driver_qemu_impl.a and libvirt_driver_network_impl.a, the compilation passed. Otherwise, failed.
I think this should be a gcc's bug, but nevermind, just fix it in libvirt.
No, it's not a bug in gcc, but an actual bug in libvirt. If you can't rely on lazy resolution (such as on platforms like mingw, except that mingw doesn't build qemumonitortestutils in the first place), then libraries MUST be listed in the order in which later libraries satisfy symbols used by earlier libraries.
How do I check whether I am relying on lazy link?
ACK, although I'd like to touch up your commit message (and in particular mention the platform where this matters) before pushing.