[adding bug-gnulib]
On 09/28/2010 06:36 AM, Justin Clift wrote:
This addresses a compilation failure issue reported last year on
OS X:
https://www.redhat.com/archives/libvir-list/2009-May/msg00166.html
which in turn mentions:
>
> gcc -Wall -Wformat -Wmissing-prototypes -Wnested-externs -Wpointer- arith -Wextra
-Wshadow -Wcast-align -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Winline
-Wredundant-decls -Wno-sign-compare -Wp,- D_FORTIFY_SOURCE=2 -fexceptions
-fasynchronous-unwind-tables -g -O2 - o .libs/event-test event_test-event-test.o
-L/opt/local/lib ../../../ src/.libs/libvirt.dylib -L/usr/lib /usr/lib/libxml2.dylib
-licucore - lm /opt/local/lib/libgnutls.dylib /opt/local/lib/libtasn1.dylib -lz /
opt/local/lib/libgcrypt.dylib /opt/local/lib/libgpg-error.dylib - lpthread
/opt/local/lib/libintl.dylib /opt/local/lib/libiconv.dylib -lc
>
> Undefined symbols:
> "_rpl_poll$UNIX2003", referenced from:
> _main in event_test-event-test.o
> ld: symbol(s) not found
> collect2: ld returned 1 exit status
> make[2]: *** [event-test] Error 1
> make[1]: *** [all-recursive] Error 1
> make: *** [all] Error 2
>
>
> The UNIX2003 symbol does not exist in 10.4, only in 10.5.
>
But the failed link mentions rpl_poll, not poll, which means this is
most likely a gnulib bug in the poll module. Rather than skipping this
test on just 32-bit MacOS in libvirt, I think the better thing to do is
address why gnulib is triggering a link failure in the first place.
In testing here, the compilation only fails on 32 bit OS X, but
works
on 64 bit, even when using exact same compile and linking flags.
This commit surgically disables compilation of this one example program
on 32 bit Mac OS X (only). Compilation still occurs, with a working
executable produced, on 64 bit Mac OS X.
---
examples/domain-events/events-c/event-test.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
--
Eric Blake eblake(a)redhat.com +1-801-349-2682
Libvirt virtualization library
http://libvirt.org