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.