10:22 a.m.
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
10:35 a.m.
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)
10:34 a.m.
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
10:41 a.m.
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)
10:50 a.m.
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
11:09 a.m.
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)
11:12 a.m.
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 -=|
11:20 a.m.
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)
11:24 a.m.
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?
No. A diff shows the following results:
<diff>
10c10
< * Authors: Ross Biro
---
* Authors: Ross Biro, <bir7(a)leland.Stanford.Edu>
84,85d83
< #define SIOCWANDEV 0x894A /* get/set netdev
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
11:14 a.m.
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.
11:54 a.m.
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
11:57 a.m.
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 -=|
12:15 p.m.
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
6412
days inactive
6412
days old
12 comments
4 participants
participants (4)
-
Daniel P. Berrange -
Jan Michael -
Mark McLoughlin -
Richard W.M. Jones