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. > > -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list