blob: 02d8cd1a719cb08153e63dc79670a9446cb8de08 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
<think>
Okay, so I'm looking at this bug report about QEMU failing to build on OpenBSD because of issues in the SLIRP code. The error messages mention things like redefinition of 'struct arphdr' and missing members in that struct. Let me break this down.
First, SLIRP is a userspace networking stack used by QEMU for virtual machines. So it's part of QEMU's user-mode networking setup. That suggests the issue might be related to how QEMU interacts with network configurations without requiring kernel privileges.
The errors are happening during compilation when including headers. The compiler says that 'struct arphdr' is redefined. Looking at the code, slirp.h defines this struct, but so does the system's net/if_arp.h. So there's a conflict between SLIRP's definition and the system's.
The errors then point out that certain members like 'ar_tip', 'ar_sip', etc., aren't found in 'struct arphdr'. These are part of the standard ARPHDR struct, so it seems like the system headers have different member names or structure than what SLIRP expects. Maybe OpenBSD uses a different naming convention or layout for this struct.
Since the issue arises when including both slirp.h and the system's net/if_arp.h, perhaps there's a compatibility problem. Maybe SLIRP should avoid defining its own arphdr if the system provides it. Alternatively, they might need to adjust how they handle these structs to match what the system expects.
The fact that this regression happened between 2.6 and 2.7 suggests a recent change in QEMU's SLIRP code caused this conflict. It could be related to header includes or struct definitions being modified without considering different OS standards.
So, considering all this, it seems like the problem is with how SLIRP interacts with the networking stack at the user level. Since SLIRP runs in user space and doesn't require kernel mode, this bug is likely a user-mode issue.
</think>
user
|