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
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,
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 headerf
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:
10c10
< * Authors: Ross Biro
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,
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
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
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
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
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-QEM
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 disab
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 Q
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
13 matches
Mail list logo
