[Libvir] build problems with latest cvs version
Hi libvirt-list, I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version. In libvirt directory I did the following (for cvs version) ./autogen.sh --disable-shared --disable-QEMU I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment). The make process breaks while building in [/opt/test/libvirt/qemud], while doing the following: <make output> if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I/usr/include/libxml2 -I../ include -I../include -I/usr/include/libxml2 -Wp,-D_FORTIFY_SOURCE=2 - fexceptions -fasynchronous-unwind-tables -Wall -Wmissing-prototypes - Wnested-externs -Wpointer-arith -Wextra -Wshadow -Wcast-align -Wwrite- strings -Waggregate-return -Wstrict-prototypes -Winline -Wredundant- decls -Wno-sign-compare -DLOCAL_STATE_DIR="\"/usr/local/var\"" - DSYSCONF_DIR="\"/usr/local/etc\"" -DQEMUD_PID_FILE="\"/usr/local/var/ run/libvirt_qemud.pid\"" -g -O2 -MT libvirt_qemud-bridge.o -MD -MP - MF ".deps/libvirt_qemud-bridge.Tpo" -c -o libvirt_qemud-bridge.o `test -f 'bridge.c' || echo './'`bridge.c; \ then mv -f ".deps/libvirt_qemud-bridge.Tpo" ".deps/libvirt_qemud- bridge.Po"; else rm -f ".deps/libvirt_qemud-bridge.Tpo"; exit 1; fi bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function) bridge.c:130: error: (Each undeclared identifier is reported only once bridge.c:130: error: for each function it appears in.) bridge.c: In function `brDeleteBridge': bridge.c:148: error: `SIOCBRDELBR' undeclared (first use in this function) bridge.c: In function `brAddInterface': bridge.c:182: error: `SIOCBRADDIF' undeclared (first use in this function) bridge.c: In function `brDeleteInterface': bridge.c:190: error: `SIOCBRDELIF' undeclared (first use in this function) bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:481: error: syntax error before string constant bridge.c:481: warning: empty body in an if-statement bridge.c: In function `brGetForwardDelay': bridge.c:503: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:503: error: syntax error before string constant bridge.c:503: warning: empty body in an if-statement bridge.c: In function `brSetEnableSTP': bridge.c:531: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:531: error: syntax error before string constant bridge.c:531: warning: empty body in an if-statement bridge.c: In function `brGetEnableSTP': bridge.c:553: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function) bridge.c:553: error: syntax error before string constant bridge.c:553: warning: empty body in an if-statement </make output> I get the same even on the older versions 0.2.2 and 0.2.1. Can you please help me to solve this compilation error? Many thanks in advance, Jan Michael
Jan Michael wrote:
Hi libvirt-list,
I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version.
In libvirt directory I did the following (for cvs version)
./autogen.sh --disable-shared --disable-QEMU
I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment).
Is this on Linux? Which kernel version? Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
Richard W.M. Jones wrote:
Jan Michael wrote:
Hi libvirt-list, I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version. In libvirt directory I did the following (for cvs version) ./autogen.sh --disable-shared --disable-QEMU I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment).
Is this on Linux? Which kernel version?
Sure. This machine is running Linux 2.6.18 SMP Wed Nov 29 21:05:58 CET 2006 i686 i686 i386 GNU/Linux. I would like to use libvirt mainly to monitor and manage xen but later also kvm. Thanks, Jan
Jan Michael wrote:
Richard W.M. Jones wrote:
Jan Michael wrote:
Hi libvirt-list, I run into the same build problem with version libvirt version 0.2.1, 0.2.2 and the latest cvs-version. In libvirt directory I did the following (for cvs version) ./autogen.sh --disable-shared --disable-QEMU I'd like to disable shared libraries and QEMU support (I have only installed xen 3.0.3 envrionment).
Is this on Linux? Which kernel version?
Sure. This machine is running Linux 2.6.18 SMP
That's odd - I was expecting you were going to say you were running something more ancient. Next question then :-) What happens if you do: $ grep SIOCBRADDBR /usr/include/linux/sockios.h for me: #define SIOCBRADDBR 0x89a0 /* create new bridge device */ Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
Richard W.M. Jones wrote:
That's odd - I was expecting you were going to say you were running something more ancient.
Next question then :-)
What happens if you do:
$ grep SIOCBRADDBR /usr/include/linux/sockios.h
for me:
#define SIOCBRADDBR 0x89a0 /* create new bridge device */
Well ... the following: <command> [xxxxxxxx@xenmachine libvirt]# grep SIOCBRADDBR /usr/include/linux/ sockios.h [xxxxxxxx@xenmachine libvirt]# </command> I think you expected at least something like that: <stuff> #define SIOCBRADDBR 0x89a0 /* create new bridge device */ </stuff> This line I grabbed from my non-xen-based laptop running on <uname> Linux nonxenmachine 2.6.20-gentoo-r7 #3 PREEMPT Fri May 4 11:03:57 CEST 2007 i686 Intel(R) Pentium(R) M processor 1500MHz GenuineIntel GNU/Linux </uname> What does this mean? Can you give me a short explanation? Do I need to update my kernel? Is it possible to use a precompiled version of libvirt from a similar system? Thanks, Jan
Jan Michael wrote:
Richard W.M. Jones wrote:
That's odd - I was expecting you were going to say you were running something more ancient.
Next question then :-)
What happens if you do:
$ grep SIOCBRADDBR /usr/include/linux/sockios.h
for me:
#define SIOCBRADDBR 0x89a0 /* create new bridge device */
Well ... the following:
<command> [xxxxxxxx@xenmachine libvirt]# grep SIOCBRADDBR /usr/include/linux/sockios.h [xxxxxxxx@xenmachine libvirt]#
This is very strange. In 2.6.18 vanilla kernel, this macro is present: http://lxr.linux.no/source/include/linux/sockios.h?v=2.6.18#L120 Does your copy of linux/sockios.h look like that one? Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
On Fri, May 04, 2007 at 05:09:45PM +0100, Richard W.M. Jones wrote:
Jan Michael wrote:
Richard W.M. Jones wrote:
That's odd - I was expecting you were going to say you were running something more ancient.
Next question then :-)
What happens if you do:
$ grep SIOCBRADDBR /usr/include/linux/sockios.h
for me:
#define SIOCBRADDBR 0x89a0 /* create new bridge device */
Well ... the following:
<command> [xxxxxxxx@xenmachine libvirt]# grep SIOCBRADDBR /usr/include/linux/sockios.h [xxxxxxxx@xenmachine libvirt]#
This is very strange. In 2.6.18 vanilla kernel, this macro is present:
http://lxr.linux.no/source/include/linux/sockios.h?v=2.6.18#L120
Does your copy of linux/sockios.h look like that one?
I think the trouble is that traditionally userspace builds didn't use the actual kernel headers. In Fedora historically there was a glibc-kernheads which had a set of header files not tracking any particular kernel release. Looking at the way bridge-utils in FC5 worked, they patched in a custom version of sockios.h to get access to the bridge constants. Perhaps we'll have to do similar in libvirt or find a different way to call the bridge stuff. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Daniel P. Berrange wrote:
I think the trouble is that traditionally userspace builds didn't use the actual kernel headers. In Fedora historically there was a glibc-kernheads which had a set of header files not tracking any particular kernel release.
Looking at the way bridge-utils in FC5 worked, they patched in a custom version of sockios.h to get access to the bridge constants. Perhaps we'll have to do similar in libvirt or find a different way to call the bridge stuff.
Running brctl directly perhaps? Rich. -- Emerging Technologies, Red Hat http://et.redhat.com/~rjones/ 64 Baker Street, London, W1U 7DF Mobile: +44 7866 314 421 Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA) and David Owens (Ireland)
Richard W.M. Jones wrote:
This is very strange. In 2.6.18 vanilla kernel, this macro is present:
http://lxr.linux.no/source/include/linux/sockios.h?v=2.6.18#L120
Does your copy of linux/sockios.h look like that one?
* Authors: Ross Biro, <bir7@leland.Stanford.Edu> 84,85d83 < #define SIOCWANDEV 0x894A /* get/set netdev
No. A diff shows the following results: <diff> 10c10 < * Authors: Ross Biro --- parameters */ < 119,124d116 < /* bridge calls */ < #define SIOCBRADDBR 0x89a0 /* create new bridge device */ < #define SIOCBRDELBR 0x89a1 /* remove bridge device */ < #define SIOCBRADDIF 0x89a2 /* add interface to bridge */ < #define SIOCBRDELIF 0x89a3 /* remove interface from bridge */ </diff> Next step? Cheers, Jan
On Fri, 2007-05-04 at 17:22 +0200, Jan Michael wrote:
bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function)
As Rich says, this should certainly be in the 2.6.20 kernel.
bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function)
To get this you want libsysfs. If you don't have it, just build with --disable-bridge-params and you probably won't notice any difference. Cheers, Mark.
Mark McLoughlin wrote:
On Fri, 2007-05-04 at 17:22 +0200, Jan Michael wrote:
bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function)
As Rich says, this should certainly be in the 2.6.20 kernel.
I replaced the the wrong headerfile with this one from the original 2.6.18 sources.
bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function)
To get this you want libsysfs. If you don't have it, just build with --disable-bridge-params and you probably won't notice any difference.
I did the configure step with the following parameters including -- disable-bridge-params as suggested by Mark: ./configure --disable-shared --disable-bridge-params --with-test=no --with-qemu=no But make failed again. This time in libvirt/test directory. Is this mandatory for using libvirt? <make error> gcc -g -O2 -o xmlrpctest xmlrpctest.o testutils.o xmlrpc.o -L/usr/ lib /usr/lib/libxml2.so -lz -lpthread -lm -lxenstore xmlrpctest.o(.text+0x24b): In function `testMarshalRequestINT': /opt/test/libvirt/tests/xmlrpctest.c:142: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x27b):/opt/test/libvirt/tests/xmlrpctest.c:142: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x2c2): In function `testMarshalRequestSTRING': /opt/test/libvirt/tests/xmlrpctest.c:158: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x2f0):/opt/test/libvirt/tests/xmlrpctest.c:158: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x349): In function `testMarshalRequestDOUBLE': /opt/test/libvirt/tests/xmlrpctest.c:175: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x377):/opt/test/libvirt/tests/xmlrpctest.c:175: more undefined references to `virBufferFree' follow xmlrpctest.o(.text+0x396): In function `testBufferStrcat': /opt/test/libvirt/tests/xmlrpctest.c:182: undefined reference to `virBufferNew' xmlrpctest.o(.text+0x3ba):/opt/test/libvirt/tests/xmlrpctest.c:186: undefined reference to `virBufferStrcat' xmlrpctest.o(.text+0x3c9):/opt/test/libvirt/tests/xmlrpctest.c:188: undefined reference to `virBufferFree' xmlrpctest.o(.text+0x3e6): In function `testBufferVSprintf': /opt/test/libvirt/tests/xmlrpctest.c:195: undefined reference to `virBufferNew' xmlrpctest.o(.text+0x401):/opt/test/libvirt/tests/xmlrpctest.c:199: undefined reference to `virBufferVSprintf' xmlrpctest.o(.text+0x410):/opt/test/libvirt/tests/xmlrpctest.c:201: undefined reference to `virBufferFree' xmlrpc.o(.text+0x22): In function `xmlRpcError': ../src/xmlrpc.c:41: undefined reference to `__virErrorMsg' xmlrpc.o(.text+0x3e):../src/xmlrpc.c:42: undefined reference to `__virRaiseError' xmlrpc.o(.text+0x76b): In function `xmlRpcValueMarshal': ../src/xmlrpc.c:313: undefined reference to `virBufferVSprintf' xmlrpc.o(.text+0x78e):../src/xmlrpc.c:332: undefined reference to `virBufferVSprintf' xmlrpc.o(.text+0x7bf):../src/xmlrpc.c:360: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x7d2):../src/xmlrpc.c:316: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x82b):../src/xmlrpc.c:322: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x851):../src/xmlrpc.c:325: undefined reference to `virBufferVSprintf' xmlrpc.o(.text+0x867):../src/xmlrpc.c:326: undefined reference to `virBufferVSprintf' xmlrpc.o(.text+0x88a):../src/xmlrpc.c:329: undefined reference to `virBufferVSprintf' xmlrpc.o(.text+0x92d):../src/xmlrpc.c:356: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x94a): In function `xmlRpcMarshalRequest': ../src/xmlrpc.c:372: undefined reference to `virBufferNew' xmlrpc.o(.text+0x968):../src/xmlrpc.c:374: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x97e):../src/xmlrpc.c:380: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x99f):../src/xmlrpc.c:383: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x9b5):../src/xmlrpc.c:386: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0xde5): In function `xmlRpcCall': ../src/xmlrpc.c:594: undefined reference to `virBufferFree' xmlrpc.o(.text+0x7b1): In function `xmlRpcValueMarshal': ../src/xmlrpc.c:363: undefined reference to `virBufferStrcat' xmlrpc.o(.text+0x90b):../src/xmlrpc.c:363: undefined reference to `virBufferStrcat' collect2: ld returned 1 exit status make[3]: *** [xmlrpctest] Error 1 make[3]: Leaving directory `/opt/test/libvirt/tests' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/opt/test/libvirt/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/opt/test/libvirt' </make error> I already tried to disable the testing feature with --with-test=no. But I suppose that this is not the right way. Cheers, Jan
On Fri, May 04, 2007 at 06:54:52PM +0200, Jan Michael wrote:
Mark McLoughlin wrote:
On Fri, 2007-05-04 at 17:22 +0200, Jan Michael wrote:
bridge.c: In function `brAddBridge': bridge.c:130: error: `SIOCBRADDBR' undeclared (first use in this function)
As Rich says, this should certainly be in the 2.6.20 kernel.
I replaced the the wrong headerfile with this one from the original 2.6.18 sources.
bridge.c: In function `brSetForwardDelay': bridge.c:481: error: `SYSFS_BRIDGE_ATTR' undeclared (first use in this function)
To get this you want libsysfs. If you don't have it, just build with --disable-bridge-params and you probably won't notice any difference.
I did the configure step with the following parameters including -- disable-bridge-params as suggested by Mark:
./configure --disable-shared --disable-bridge-params --with-test=no --with-qemu=no
But make failed again. This time in libvirt/test directory. Is this mandatory for using libvirt?
<make error> gcc -g -O2 -o xmlrpctest xmlrpctest.o testutils.o xmlrpc.o -L/usr/ lib /usr/lib/libxml2.so -lz -lpthread -lm -lxenstore xmlrpctest.o(.text+0x24b): In function `testMarshalRequestINT': /opt/test/libvirt/tests/xmlrpctest.c:142: undefined reference to `virBufferFree'
[snip]
</make error>
I already tried to disable the testing feature with --with-test=no. But I suppose that this is not the right way.
The --with-test disables the 'test' hypervisor driver, not the test suite. The problem you see is because you used '--disable-shared' in the configure script. We aren't currently able to build the test suite if shared libraries are disabled. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Hi Dan, Daniel P. Berrange wrote:
I did the configure step with the following parameters including -- disable-bridge-params as suggested by Mark:
./configure --disable-shared --disable-bridge-params --with-test=no --with-qemu=no
But make failed again. This time in libvirt/test directory. Is this mandatory for using libvirt?
<make error> gcc -g -O2 -o xmlrpctest xmlrpctest.o testutils.o xmlrpc.o -L/usr/ lib /usr/lib/libxml2.so -lz -lpthread -lm -lxenstore xmlrpctest.o(.text+0x24b): In function `testMarshalRequestINT': /opt/test/libvirt/tests/xmlrpctest.c:142: undefined reference to `virBufferFree'
[snip]
</make error>
I already tried to disable the testing feature with --with-test=no. But I suppose that this is not the right way.
The --with-test disables the 'test' hypervisor driver, not the test suite. The problem you see is because you used '--disable-shared' in the configure script. We aren't currently able to build the test suite if shared libraries are disabled.
Wow. That worked. Libvirt is now compiled. Thanks a lot for your help guys. Cheers, Jan
participants (4)
-
Daniel P. Berrange -
Jan Michael -
Mark McLoughlin -
Richard W.M. Jones