On 11/20/14, 18:54 , "John Ferlan" <jferlan@redhat.com> wrote:
On 11/20/2014 01:19 PM, Eric Blake wrote:
On 11/20/2014 11:11 AM, John Ferlan wrote:
However, for some reason I see this build error after 2/5:
make[3]: Entering directory '/home/zippy/work/libvirt/libvirt.git/tools/wireshark/src' CC libvirt_la-packet-libvirt.lo In file included from libvirt/protocol.h:5:0, from packet-libvirt.h:112, from packet-libvirt.c:36: ./libvirt/remote.h: In function 'dissect_xdr_remote_typed_param_value': ./libvirt/remote.h:470:5: error: unknown type name 'remote_nonnull_string' remote_nonnull_string type = 0; ^
Strange - I don't see this. My ./tools/wireshark/src/libvirt/remote.h doesn't even have that line. Stranger still, my config.log (after make clean; ./autogen.sh --system; make j4) has:
configure:69348: checking for wireshark configure:69381: result: no
Could it be environmental? Could it be some config option? Perhaps something installed? I have for wireshark on my f20 system:
wireshark.x86_64 1.10.10-1.fc20 @updates
You need wireshark-devel before configure will build wireshark interactions into libvirt.
So, yes installing wireshark-devel results in a failure for me to.
So, I stopped after 1/5 and modified the "location" of the definitions in remote_protocol.x for remote_domain_fsinfo {}.
If move just:
struct remote_domain_fsinfo { remote_nonnull_string mountpoint; remote_nonnull_string name; remote_nonnull_string type; remote_nonnull_string dev_aliases<REMOTE_DOMAIN_FSINFO_DISKS_MAX>; /* (const char **) */ };
to anywhere (I tested) before:
struct remote_network_dhcp_lease { remote_nonnull_string iface; hyper expirytime; int type; remote_string mac; remote_string iaid; remote_nonnull_string ipaddr; unsigned int prefix; remote_string hostname; remote_string clientid; };
Then the build succeeds; however, afterwards it fails. I even tried changing "dev_aliases" to "devAliases" to see if that would help - it didn't.
If I move those dhcp defs to after the get_fsinfo defs, things work fine again. Perhaps there's something in tools/wireshark/util/genxdrstub.pl or something in that dhcp_lease def.
I'm not quite sure what the issue is.
John
I could reproduce this issue, and it looks like I can avoid the issue by renaming the ¹type¹ field to Œfstype¹. Now investigating why this happens... Thanks, Tomoki