[libvirt] [PATCH] Fix test case qemuagenttest compilation.

[Jincheng Miao]

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.
>
>