[libvirt] Minor compile failure on OSX for libvirt 2.0.0
Hi all, There's a minor compile failure on OSX with libvirt 2.0.0: CC util/libvirt_util_la-virtime.lo CC util/libvirt_util_la-virtpm.lo util/virsystemd.c:524:26: error: use of undeclared identifier 'MSG_NOSIGNAL' if (sendmsg(fd, &mh, MSG_NOSIGNAL) < 0) ^ 1 error generated. make[3]: *** [util/libvirt_util_la-virsystemd.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Seems solvable by adding a stub declaration for MSG_NOSIGNAL on systems that don't implement it. An initial patch with the declaration, developed by Tomasz Pajor (CC'd), is below: --- src/util/virsystemd.h.orig 2016-07-03 21:40:12.000000000 +0200 +++ src/util/virsystemd.h 2016-07-03 21:37:53.000000000 +0200 @@ -57,3 +57,7 @@ char *virSystemdGetMachineNameByPID(pid_t pid); #endif /* __VIR_SYSTEMD_H__ */ + +#ifndef MSG_NOSIGNAL +#define MSG_NOSIGNAL 0x0 //Don't request NOSIGNAL on systems where this is not implemented. +#endif It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Sat, 2016-07-16 at 11:16 +0100, Justin Clift wrote:
Hi all, There's a minor compile failure on OSX with libvirt 2.0.0: CC util/libvirt_util_la-virtime.lo CC util/libvirt_util_la-virtpm.lo util/virsystemd.c:524:26: error: use of undeclared identifier 'MSG_NOSIGNAL' if (sendmsg(fd, &mh, MSG_NOSIGNAL) < 0) ^ 1 error generated. make[3]: *** [util/libvirt_util_la-virsystemd.lo] Error 1 make[3]: *** Waiting for unfinished jobs.... Seems solvable by adding a stub declaration for MSG_NOSIGNAL on systems that don't implement it. An initial patch with the declaration, developed by Tomasz Pajor (CC'd), is below: --- src/util/virsystemd.h.orig 2016-07-03 21:40:12.000000000 +0200 +++ src/util/virsystemd.h 2016-07-03 21:37:53.000000000 +0200 @@ -57,3 +57,7 @@ char *virSystemdGetMachineNameByPID(pid_t pid); #endif /* __VIR_SYSTEMD_H__ */ + +#ifndef MSG_NOSIGNAL +#define MSG_NOSIGNAL 0x0 //Don't request NOSIGNAL on systems where this is not implemented. +#endif It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :)
I have posted a tentative patch to fix your issue https://www.redhat.com/archives/libvir-list/2016-July/msg00724.html Can you please check it out and confirm whether it works or not? I don't have any OS X host where I can test it myself. To be honest, I don't see why we're compiling the systemd support code on OS X at all. But I don't have the time to dig further right now :) -- Andrea Bolognani / Red Hat / Virtualization
On 19 Jul 2016, at 15:03, Andrea Bolognani <abologna@redhat.com> wrote: <snip>
It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :)
I have posted a tentative patch to fix your issue
https://www.redhat.com/archives/libvir-list/2016-July/msg00724.html
Can you please check it out and confirm whether it works or not? I don't have any OS X host where I can test it myself.
To be honest, I don't see why we're compiling the systemd support code on OS X at all. But I don't have the time to dig further right now :)
Oops, it didn't click for me that this is systemd code. You're right, there's no need for that to be compiled on OSX. :) Looking at the output from ./configure, there doesn't seem to be a switch for disabling systemd stuff. Did I overlook something? :) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Tue, 2016-07-19 at 16:30 +0100, Justin Clift wrote:
It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :) I have posted a tentative patch to fix your issue https://www.redhat.com/archives/libvir-list/2016-July/msg00724.html Can you please check it out and confirm whether it works or not? I don't have any OS X host where I can test it myself. To be honest, I don't see why we're compiling the systemd support code on OS X at all. But I don't have the time to dig further right now :) Oops, it didn't click for me that this is systemd code. You're right,
On 19 Jul 2016, at 15:03, Andrea Bolognani <abologna@redhat.com> wrote: <snip> there's no need for that to be compiled on OSX. :) Looking at the output from ./configure, there doesn't seem to be a switch for disabling systemd stuff. Did I overlook something? :)
You didn't overlook anything: there's simply no way to compile the systemd support conditionally, at least at the moment :) Did you manage to build and run libvirt succesfully with the patch I posted? -- Andrea Bolognani / Red Hat / Virtualization
On 19 Jul 2016, at 17:58, Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2016-07-19 at 16:30 +0100, Justin Clift wrote:
On 19 Jul 2016, at 15:03, Andrea Bolognani <abologna@redhat.com> wrote: <snip>
It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :)
I have posted a tentative patch to fix your issue
https://www.redhat.com/archives/libvir-list/2016-July/msg00724.html
Can you please check it out and confirm whether it works or not? I don't have any OS X host where I can test it myself.
To be honest, I don't see why we're compiling the systemd support code on OS X at all. But I don't have the time to dig further right now :)
Oops, it didn't click for me that this is systemd code. You're right, there's no need for that to be compiled on OSX. :)
Looking at the output from ./configure, there doesn't seem to be a switch for disabling systemd stuff.
Did I overlook something? :)
You didn't overlook anything: there's simply no way to compile the systemd support conditionally, at least at the moment :)
Did you manage to build and run libvirt succesfully with the patch I posted?
Not yet. It barfed at me due to a system config problem which I need to investigate and haven't done yet. Probably get around to it later today. :) Thinking out loud... is the systemd code compiled for BSD? Guessing not (without checking :>), so there's probably some kind of #ifdef to automatically exclude it. If that's how things are setup at present, would the optimal approach be to adjust such an #ifdef to also exclude OSX? + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Tue, Jul 19, 2016 at 06:30:47PM +0100, Justin Clift wrote:
On 19 Jul 2016, at 17:58, Andrea Bolognani <abologna@redhat.com> wrote:
On Tue, 2016-07-19 at 16:30 +0100, Justin Clift wrote:
On 19 Jul 2016, at 15:03, Andrea Bolognani <abologna@redhat.com> wrote: <snip>
It's outside the #endif for __VIR_SYSTEMD_H___ though, so I'm kind of thinking it would need to be move inside the guard (which also compiles ok), or is there a better place/file for it instead? :)
I have posted a tentative patch to fix your issue
https://www.redhat.com/archives/libvir-list/2016-July/msg00724.html
Can you please check it out and confirm whether it works or not? I don't have any OS X host where I can test it myself.
To be honest, I don't see why we're compiling the systemd support code on OS X at all. But I don't have the time to dig further right now :)
Oops, it didn't click for me that this is systemd code. You're right, there's no need for that to be compiled on OSX. :)
Looking at the output from ./configure, there doesn't seem to be a switch for disabling systemd stuff.
Did I overlook something? :)
You didn't overlook anything: there's simply no way to compile the systemd support conditionally, at least at the moment :)
Did you manage to build and run libvirt succesfully with the patch I posted?
Not yet. It barfed at me due to a system config problem which I need to investigate and haven't done yet. Probably get around to it later today. :)
Thinking out loud... is the systemd code compiled for BSD?
Guessing not (without checking :>), so there's probably some kind of #ifdef to automatically exclude it. If that's how things are setup at present, would the optimal approach be to adjust such an #ifdef to also exclude OSX?
Unfortunately the systemd code is compiled everywhere. We use no library or header file. AFAIK the only way we communicate with systemd is DBus (and one socket maybe), anyway if that's not available we just fallback without an error, so the code is designed to work with or without systemd, no need to recompile anything. OTOH it adds unused code for platforms where it won't be used at all. At least for now ;)
+ Justin
-- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On 20 Jul 2016, at 12:21, Martin Kletzander <mkletzan@redhat.com> wrote:
On Tue, Jul 19, 2016 at 06:30:47PM +0100, Justin Clift wrote:
On 19 Jul 2016, at 17:58, Andrea Bolognani <abologna@redhat.com> wrote: <snip>
Did you manage to build and run libvirt succesfully with the patch I posted?
Not yet. It barfed at me due to a system config problem which I need to investigate and haven't done yet. Probably get around to it later today. :)
Thinking out loud... is the systemd code compiled for BSD?
Guessing not (without checking :>), so there's probably some kind of #ifdef to automatically exclude it. If that's how things are setup at present, would the optimal approach be to adjust such an #ifdef to also exclude OSX?
Unfortunately the systemd code is compiled everywhere. We use no library or header file. AFAIK the only way we communicate with systemd is DBus (and one socket maybe), anyway if that's not available we just fallback without an error, so the code is designed to work with or without systemd, no need to recompile anything. OTOH it adds unused code for platforms where it won't be used at all. At least for now ;)
Thanks Martin. :) I'll put more time into investigating why the patch barfed for me. I think it'll just be something simple like forgetting to set the time/date stamp of the patched file so make doesn't try to regenerate ./configure again. Will find out. ;) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On Wed, 2016-07-20 at 13:28 +0100, Justin Clift wrote:
I'll put more time into investigating why the patch barfed for me. I think it'll just be something simple like forgetting to set the time/date stamp of the patched file so make doesn't try to regenerate ./configure again. Will find out. ;)
Sounds to me like your build environment is kinda broken... You really shouldn't need to do anything like that, just 'git am' the commit and 'make' away. As a simple sanity check, can you compile libvirt 1.3.5 successfully? If you post the error message you're getting we'll of course try to help you out to the best of our possibilities :) -- Andrea Bolognani / Red Hat / Virtualization
On 20 Jul 2016, at 13:43, Andrea Bolognani <abologna@redhat.com> wrote:
On Wed, 2016-07-20 at 13:28 +0100, Justin Clift wrote:
I'll put more time into investigating why the patch barfed for me. I think it'll just be something simple like forgetting to set the time/date stamp of the patched file so make doesn't try to regenerate ./configure again. Will find out. ;)
Sounds to me like your build environment is kinda broken... You really shouldn't need to do anything like that, just 'git am' the commit and 'make' away. As a simple sanity check, can you compile libvirt 1.3.5 successfully?
Yeah, libvirt 1.3.5 is fine. The problem here is that getting this tested in OSX has some pita niggles that needing working around, and it's been a fair while since I last needed to do them. eg out of practise :) In this instance, because this is intended for use in Homebrew (an OSX packaging system) I need to test the patch with the already generated libvirt-2.0.0.xz archive, not the latest git master. Cue unpacking, applying patch, repacking, etc. I'm on it now. ;)
If you post the error message you're getting we'll of course try to help you out to the best of our possibilities :)
Sure. Lets see if my 2nd attempt at regenerating patched archive file work first... :) + Justin -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
On 20 Jul 2016, at 13:57, Justin Clift <justin@postgresql.org> wrote: On 20 Jul 2016, at 13:43, Andrea Bolognani <abologna@redhat.com> wrote: <snip>
If you post the error message you're getting we'll of course try to help you out to the best of our possibilities :)
Sure. Lets see if my 2nd attempt at regenerating patched archive file work first... :)
Good news, your patch works fine. :) The config error on my end was indeed just due to forgetting to reset the timestamps on the patched files. After doing that, libvirt-2.0.0 (with your patch) compiled fine. virsh seems to run ok too, so from my point of view "good enough". :) Regards and best wishes, Justin Clift -- "My grandfather once told me that there are two kinds of people: those who work and those who take the credit. He told me to try to be in the first group; there was less competition there." - Indira Gandhi
participants (3)
-
Andrea Bolognani -
Justin Clift -
Martin Kletzander