Re: [libvirt] [PATCH] tests: Avoid double linking some libraries
On 07/03/2014 08:44 AM, John Ferlan wrote:
On 07/03/2014 08:34 AM, Michal Privoznik wrote:
> The problem is, since 614581f32b domaincapstest is linked with
> $(LDADDS) by default. Then, since 94e3f23e8a7 the test may be
> conditionally linked with $(qemu_LDADDS) which already contains
> $(LDADDS). And some linkers doesn't cope with this nicely:
>
> CCLD domaincapstest
> ../src/libvirt_probes.o:(.probes+0x0): multiple definition of
`libvirt_event_poll_add_handle_semaphore'
> ../src/libvirt_probes.o:(.probes+0x0): first defined here
> ../src/libvirt_probes.o:(.probes+0x2): multiple definition of
`libvirt_event_poll_update_handle_semaphore'
> ../src/libvirt_probes.o:(.probes+0x2): first defined here
> ../src/libvirt_probes.o:(.probes+0x4): multiple definition of
`libvirt_event_poll_remove_handle_semaphore'
> ../src/libvirt_probes.o:(.probes+0x4): first defined here
> ../src/libvirt_probes.o:(.probes+0x6): multiple definition of
`libvirt_event_poll_dispatch_handle_semaphore'
> ../src/libvirt_probes.o:(.probes+0x6): first defined here
>
> And so on.
>
> Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
> ---
>
> I'd push this as build breaker, but there's another approach to consider,
> create qemu_BARE_LDADDS and fill it with the qemu_impl, etc. Then, let:
> qemu_LDADDS = $(qemu_BARE_LDADDS) $(LDADDS)
>
> What's your preference?
>
What is below works for me - so to that degree I'd ACK. However, if
someone had a preference for whatever it is you're describing as an
option, then I suppose that would be fine too. Makefile's are mostly
black magic to me :-)
John
Let me amend my last statement - something is not quite working...
I tried to apply this patch to other work I'm doing and things fell
apart with missing symbols. If I try to reset my environment back to
the top of the tree, then the build seems to work fine... If I apply
this patch, then things fall apart in the same way.
It's kind of difficult to describe, but there seems to be some
dependency that isn't quite right or doesn't get reset if this patch is
removed from the environment.
I think the following steps make things reproducible.
1. Start with a "clean" top...
2. Build, will get the multiple definition failure...
3. Apply this patch (git am)
4. Build - get lots of failures
5. git reset HEAD^
6. git co tests/Makefile.am
7. Build cleanly
8. git am the first change from my series
9. Build, results from step2
10. Repeat steps 3->7 for each/all of the patches from my series.
I'm still wondering why steps 3 & 4 worked for me before - perhaps
because I was testing something intermediary.
Like I said before these Makefiles are black magic to me!
John