ivshmem-server makes use of the POSIX shared memory object interfaces.
This library is provided on NetBSD in -lrt (POSIX Real-time Library).
Add ./configure check if there is needed -lrt linking for shm_open()
and if so use it. Introduce new configure generated variable LIBS_SHMLIB.
This fixes build issue on NetBSD.
Signed-off-by: Kamil Rytarowski <n54@gmx.com>
---
Makefile | 1 +
configure | 20 ++++++++++++++++++++
2 files changed, 21 insertions(+)
diff --git a/Makefile b/Makefile
index 31d41a7eae..3248cb53d7 100644
--- a/Makefile
+++ b/Makefile
@@ -473,6 +473,7 @@ ivshmem-client$(EXESUF): $(ivshmem-client-obj-y) $(COMMON_LDADDS)
$(call LINK, $^)
ivshmem-server$(EXESUF): $(ivshmem-server-obj-y) $(COMMON_LDADDS)
$(call LINK, $^)
+ivshmem-server$(EXESUF): LIBS += $(LIBS_SHMLIB)
module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak
$(call quiet-command,$(PYTHON) $< $@ \
diff --git a/configure b/configure
index 7c020c076b..50c3aee746 100755
--- a/configure
+++ b/configure
@@ -179,6 +179,7 @@ audio_pt_int=""
audio_win_int=""
cc_i386=i386-pc-linux-gnu-gcc
libs_qga=""
+libs_shmlib=""
debug_info="yes"
stack_protector=""
@@ -4133,6 +4134,24 @@ elif compile_prog "" "$pthread_lib -lrt" ; then
libs_qga="$libs_qga -lrt"
fi
+##########################################
+# Do we need librt for shm_open()
+cat > $TMPC <<EOF
+#include <sys/mman.h>
+#include <sys/stat.h>
+#include <fcntl.h>
+#include <stddef.h>
+int main(void) {
+ return shm_open(NULL, O_RDWR, 0644);
+}
+EOF
+
+if compile_prog "" "" ; then
+ :
+elif compile_prog "" "-lrt" ; then
+ libs_shmlib="$libs_shmlib -lrt"
+fi
+
if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \
"$aix" != "yes" -a "$haiku" != "yes" ; then
libs_softmmu="-lutil $libs_softmmu"
@@ -5949,6 +5968,7 @@ echo "EXESUF=$EXESUF" >> $config_host_mak
echo "DSOSUF=$DSOSUF" >> $config_host_mak
echo "LDFLAGS_SHARED=$LDFLAGS_SHARED" >> $config_host_mak
echo "LIBS_QGA+=$libs_qga" >> $config_host_mak
+echo "LIBS_SHMLIB+=$libs_shmlib" >> $config_host_mak
echo "TASN1_LIBS=$tasn1_libs" >> $config_host_mak
echo "TASN1_CFLAGS=$tasn1_cflags" >> $config_host_mak
echo "POD2MAN=$POD2MAN" >> $config_host_mak
--
2.12.2
On 05/12/2017 09:46 PM, Kamil Rytarowski wrote: > ivshmem-server makes use of the POSIX shared memory object interfaces. > This library is provided on NetBSD in -lrt (POSIX Real-time Library). > Add ./configure check if there is needed -lrt linking for shm_open() > and if so use it. Introduce new configure generated variable LIBS_SHMLIB. > > This fixes build issue on NetBSD. > > Signed-off-by: Kamil Rytarowski <n54@gmx.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> > --- > Makefile | 1 + > configure | 20 ++++++++++++++++++++ > 2 files changed, 21 insertions(+) > > diff --git a/Makefile b/Makefile > index 31d41a7eae..3248cb53d7 100644 > --- a/Makefile > +++ b/Makefile > @@ -473,6 +473,7 @@ ivshmem-client$(EXESUF): $(ivshmem-client-obj-y) $(COMMON_LDADDS) > $(call LINK, $^) > ivshmem-server$(EXESUF): $(ivshmem-server-obj-y) $(COMMON_LDADDS) > $(call LINK, $^) > +ivshmem-server$(EXESUF): LIBS += $(LIBS_SHMLIB) > > module_block.h: $(SRC_PATH)/scripts/modules/module_block.py config-host.mak > $(call quiet-command,$(PYTHON) $< $@ \ > diff --git a/configure b/configure > index 7c020c076b..50c3aee746 100755 > --- a/configure > +++ b/configure > @@ -179,6 +179,7 @@ audio_pt_int="" > audio_win_int="" > cc_i386=i386-pc-linux-gnu-gcc > libs_qga="" > +libs_shmlib="" > debug_info="yes" > stack_protector="" > > @@ -4133,6 +4134,24 @@ elif compile_prog "" "$pthread_lib -lrt" ; then > libs_qga="$libs_qga -lrt" > fi > > +########################################## > +# Do we need librt for shm_open() > +cat > $TMPC <<EOF > +#include <sys/mman.h> > +#include <sys/stat.h> > +#include <fcntl.h> > +#include <stddef.h> > +int main(void) { > + return shm_open(NULL, O_RDWR, 0644); > +} > +EOF > + > +if compile_prog "" "" ; then > + : > +elif compile_prog "" "-lrt" ; then > + libs_shmlib="$libs_shmlib -lrt" > +fi > + > if test "$darwin" != "yes" -a "$mingw32" != "yes" -a "$solaris" != yes -a \ > "$aix" != "yes" -a "$haiku" != "yes" ; then > libs_softmmu="-lutil $libs_softmmu" > @@ -5949,6 +5968,7 @@ echo "EXESUF=$EXESUF" >> $config_host_mak > echo "DSOSUF=$DSOSUF" >> $config_host_mak > echo "LDFLAGS_SHARED=$LDFLAGS_SHARED" >> $config_host_mak > echo "LIBS_QGA+=$libs_qga" >> $config_host_mak > +echo "LIBS_SHMLIB+=$libs_shmlib" >> $config_host_mak > echo "TASN1_LIBS=$tasn1_libs" >> $config_host_mak > echo "TASN1_CFLAGS=$tasn1_cflags" >> $config_host_mak > echo "POD2MAN=$POD2MAN" >> $config_host_mak >
Currently ivshmem requires eventfd() which is Linux specific.
Do not and build it unconditionally on every Linux/BSD/Solaris.
This patch indirectly fixes build failure on NetBSD, where these tools
additionally require -lrl for shm_open(3). In future there should be
added support for NetBSD and the linking addressed appropriately.
Signed-off-by: Kamil Rytarowski <n54@gmx.com>
---
configure | 2 ++
1 file changed, 2 insertions(+)
diff --git a/configure b/configure
index 1a5ee4b909..84d8660354 100755
--- a/configure
+++ b/configure
@@ -4928,6 +4928,8 @@ if test "$want_tools" = "yes" ; then
tools="qemu-img\$(EXESUF) qemu-io\$(EXESUF) $tools"
if [ "$linux" = "yes" -o "$bsd" = "yes" -o "$solaris" = "yes" ] ; then
tools="qemu-nbd\$(EXESUF) $tools"
+ fi
+ if [ "$eventfd" != "no" ]; then
tools="ivshmem-client\$(EXESUF) ivshmem-server\$(EXESUF) $tools"
fi
fi
--
2.13.0
Hi On Fri, May 26, 2017 at 9:49 AM Kamil Rytarowski <n54@gmx.com> wrote: > Currently ivshmem requires eventfd() which is Linux specific. > Do not and build it unconditionally on every Linux/BSD/Solaris. > > I think it should be able to use pipe fallback from event_notifier_init() . > This patch indirectly fixes build failure on NetBSD, where these tools > additionally require -lrl for shm_open(3). In future there should be > added support for NetBSD and the linking addressed appropriately. > > Signed-off-by: Kamil Rytarowski <n54@gmx.com> > --- > configure | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/configure b/configure > index 1a5ee4b909..84d8660354 100755 > --- a/configure > +++ b/configure > @@ -4928,6 +4928,8 @@ if test "$want_tools" = "yes" ; then > tools="qemu-img\$(EXESUF) qemu-io\$(EXESUF) $tools" > if [ "$linux" = "yes" -o "$bsd" = "yes" -o "$solaris" = "yes" ] ; then > tools="qemu-nbd\$(EXESUF) $tools" > + fi > + if [ "$eventfd" != "no" ]; then > tools="ivshmem-client\$(EXESUF) ivshmem-server\$(EXESUF) $tools" > fi > fi > -- > 2.13.0 > > > -- Marc-André Lureau
Currently ivshmem requires eventfd() which is Linux specific.
Do not and build it unconditionally on every Linux/BSD/Solaris.
This patch indirectly fixes build failure on NetBSD, where these tools
additionally require -lrt for shm_open(3). In future there should be
added support for NetBSD and the linking addressed appropriately.
Signed-off-by: Kamil Rytarowski <n54@gmx.com>
Reviewed-by: Markus Armbruster <armbru@redhat.com>
---
configure | 2 ++
contrib/ivshmem-client/Makefile.objs | 2 +-
contrib/ivshmem-server/Makefile.objs | 2 +-
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/configure b/configure
index 1a5ee4b909..483307be53 100755
--- a/configure
+++ b/configure
@@ -4928,6 +4928,8 @@ if test "$want_tools" = "yes" ; then
tools="qemu-img\$(EXESUF) qemu-io\$(EXESUF) $tools"
if [ "$linux" = "yes" -o "$bsd" = "yes" -o "$solaris" = "yes" ] ; then
tools="qemu-nbd\$(EXESUF) $tools"
+ fi
+ if [ "$eventfd" = "yes" ]; then
tools="ivshmem-client\$(EXESUF) ivshmem-server\$(EXESUF) $tools"
fi
fi
diff --git a/contrib/ivshmem-client/Makefile.objs b/contrib/ivshmem-client/Makefile.objs
index bfab2d20dd..13d864082d 100644
--- a/contrib/ivshmem-client/Makefile.objs
+++ b/contrib/ivshmem-client/Makefile.objs
@@ -1 +1 @@
-ivshmem-client-obj-y = ivshmem-client.o main.o
+ivshmem-client-obj-$(CONFIG_IVSHMEM) = ivshmem-client.o main.o
diff --git a/contrib/ivshmem-server/Makefile.objs b/contrib/ivshmem-server/Makefile.objs
index c060dd3698..d9469fd777 100644
--- a/contrib/ivshmem-server/Makefile.objs
+++ b/contrib/ivshmem-server/Makefile.objs
@@ -1 +1 @@
-ivshmem-server-obj-y = ivshmem-server.o main.o
+ivshmem-server-obj-$(CONFIG_IVSHMEM) = ivshmem-server.o main.o
--
2.11.1
On 05/30/2017 01:20 AM, Kamil Rytarowski wrote: > Currently ivshmem requires eventfd() which is Linux specific. > Do not and build it unconditionally on every Linux/BSD/Solaris. > > This patch indirectly fixes build failure on NetBSD, where these tools > additionally require -lrt for shm_open(3). In future there should be > added support for NetBSD and the linking addressed appropriately. Is this a v2 patch? If so, it's best to repost it as a new top-level thread rather than buried in reply to your v1 patch. Also, be sure to include v2 in the subject line ('git send-email -v2' works wonders for that). > > Signed-off-by: Kamil Rytarowski <n54@gmx.com> > Reviewed-by: Markus Armbruster <armbru@redhat.com> > --- It also helps in a v2 submission to list here, after the --- separator, how it differs from v1. More submission hints at http://wiki.qemu.org/Contribute/SubmitAPatch -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
On 30.05.2017 14:53, Eric Blake wrote: > On 05/30/2017 01:20 AM, Kamil Rytarowski wrote: >> Currently ivshmem requires eventfd() which is Linux specific. >> Do not and build it unconditionally on every Linux/BSD/Solaris. >> >> This patch indirectly fixes build failure on NetBSD, where these tools >> additionally require -lrt for shm_open(3). In future there should be >> added support for NetBSD and the linking addressed appropriately. > > Is this a v2 patch? If so, it's best to repost it as a new top-level > thread rather than buried in reply to your v1 patch. Also, be sure to > include v2 in the subject line ('git send-email -v2' works wonders for > that). > I reworked it, fixed title and it's more like v3. >> >> Signed-off-by: Kamil Rytarowski <n54@gmx.com> >> Reviewed-by: Markus Armbruster <armbru@redhat.com> >> --- > > It also helps in a v2 submission to list here, after the --- separator, > how it differs from v1. > > More submission hints at http://wiki.qemu.org/Contribute/SubmitAPatch > Do I still need to resend it?
On 05/30/2017 08:11 AM, Kamil Rytarowski wrote: >> >> Is this a v2 patch? If so, it's best to repost it as a new top-level >> thread rather than buried in reply to your v1 patch. Also, be sure to >> include v2 in the subject line ('git send-email -v2' works wonders for >> that). >> > > I reworked it, fixed title and it's more like v3. > > Do I still need to resend it? > A human maintainer can often (eventually) figure out what's going on if you don't, but resending is easier if you want to ensure the automated patch tools don't lose things. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Eric Blake <eblake@redhat.com> writes: > On 05/30/2017 08:11 AM, Kamil Rytarowski wrote: > >>> >>> Is this a v2 patch? If so, it's best to repost it as a new top-level >>> thread rather than buried in reply to your v1 patch. Also, be sure to >>> include v2 in the subject line ('git send-email -v2' works wonders for >>> that). >>> > >> >> I reworked it, fixed title and it's more like v3. >> > >> Do I still need to resend it? >> > > A human maintainer can often (eventually) figure out what's going on if > you don't, but resending is easier if you want to ensure the automated > patch tools don't lose things. Yes. However, ivshmem doesn't have a maintainer. Since the patch is really simple, the easiest path forward could be sending a v3 with cc: qemu-trivial@nongnu.org.
On 31.05.2017 13:11, Markus Armbruster wrote: > Eric Blake <eblake@redhat.com> writes: > >> On 05/30/2017 08:11 AM, Kamil Rytarowski wrote: >> >>>> >>>> Is this a v2 patch? If so, it's best to repost it as a new top-level >>>> thread rather than buried in reply to your v1 patch. Also, be sure to >>>> include v2 in the subject line ('git send-email -v2' works wonders for >>>> that). >>>> >> >>> >>> I reworked it, fixed title and it's more like v3. >>> >> >>> Do I still need to resend it? >>> >> >> A human maintainer can often (eventually) figure out what's going on if >> you don't, but resending is easier if you want to ensure the automated >> patch tools don't lose things. > > Yes. > > However, ivshmem doesn't have a maintainer. Since the patch is really > simple, the easiest path forward could be sending a v3 with > cc: qemu-trivial@nongnu.org. > OK, I will do this.
Kamil Rytarowski <n54@gmx.com> writes: > On 31.05.2017 13:11, Markus Armbruster wrote: >> Eric Blake <eblake@redhat.com> writes: >> >>> On 05/30/2017 08:11 AM, Kamil Rytarowski wrote: >>> >>>>> >>>>> Is this a v2 patch? If so, it's best to repost it as a new top-level >>>>> thread rather than buried in reply to your v1 patch. Also, be sure to >>>>> include v2 in the subject line ('git send-email -v2' works wonders for >>>>> that). >>>>> >>> >>>> >>>> I reworked it, fixed title and it's more like v3. >>>> >>> >>>> Do I still need to resend it? >>>> >>> >>> A human maintainer can often (eventually) figure out what's going on if >>> you don't, but resending is easier if you want to ensure the automated >>> patch tools don't lose things. >> >> Yes. >> >> However, ivshmem doesn't have a maintainer. Since the patch is really >> simple, the easiest path forward could be sending a v3 with >> cc: qemu-trivial@nongnu.org. >> > > OK, I will do this. Thank you for your patience (and the patch, of course).
© 2016 - 2024 Red Hat, Inc.