Building spice or spice-gtk from git requires python modules pyparsing
and six. Search for them in the both Python versions and set
the Python version accordingly.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
Newer lz4 headers give deprecated warning using LZ4_compress_continue
instead of LZ_compress_fast_continue so detect this function
to allow usage and avoid the warning.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Pavel Grunt <pgrunt@redhat.com>
LZ4 changed versioning scheme from r131 to v1.7.3 making our configure
fail with (1.7.3 < 129).
Switch from version checking to checking that the necessary function
is available.
Acked-by: Frediano Ziglio <fziglio@redhat.com>
The protocol file is not documented and people have to read code to
understand the specification.
This can lead to unexpected or not optimal results so it's better
to have it documented.
The m4/spice_manual.m4 came from spice server and is meant to be
reused.
Signed-off-by: Frediano Ziglio <fziglio@redhat.com>
Acked-by: Victor Toso <victortoso@redhat.com>
LZ4 data compression on spicevmc channel uses LZ4_compress_default()
API introduced in 129 release (see commit bellow)
[0] https://github.com/Cyan4973/lz4/commit/1b17bf2ab8cf66dd2b740e
Acked-by: Pavel Grunt <pgrunt@redhat.com>
Reported-by: Fabio Fantoni <fantonifabio@tiscali.it>
Add a new 'HAVE_LZ4' automake conditional to really tell if we have the
dependency installed on the system. It will later be used in Makefile to
decide whether or not the specific files related to LZ4 should be built.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
SPICE_COMMON_{CFLAGS,LIBS} references '$(GL_{CFLAGS,LIBS)', so these
variables are going to be expanded at 'make' time rather than at
'configure' time.
The linker flag and the compiler flag won't be substituted in the
generated Makefile without AC_SUBST.
It causes spice-gtk building failure with --enable-opengl option.
The patch fixes this issue.
Signed-off-by: Lin Ma <lma@suse.com>
While testing spice-server on EL6, I was getting random crashes in the
glib logging code because g_logv was called recursively even though this
was not visible in a backtrace.
It turns out on older glib versions (EL6 has 2.28), g_logv is not
thread-safe unless g_thread_init() is called first. If g_thread_init()
is not called, the GMutex/GPrivate calls g_logv makes are turned into
no-ops, which is going to cause the recursion issue I was seeing.
This commit adds a call to g_thread_init() for these older glib
versions.
(gdb) bt
0x7fff9f9fb110 "item.type: 114", unused_data=0x0) at gmessages.c:863
format=0x7ffff50e72ac "item.type: %d", args1=0x7fff9f9fb640) at gmessages.c:517
SPICE_LOG_LEVEL_DEBUG, strloc=0x7ffff50e72ba "dcc.c:1652", function=
0x7ffff50e7320 "release_item_before_push", format=0x7ffff50e72ac "item.type: %d", args=
0x7fff9f9fb640) at log.c:163
SPICE_LOG_LEVEL_DEBUG, strloc=0x7ffff50e72ba "dcc.c:1652", function=
0x7ffff50e7320 "release_item_before_push", format=0x7ffff50e72ac "item.type: %d") at log.c:195
at dcc.c:1652
at dcc.c:1719
at dcc-send.c:2450
at red-channel.c:578
at red-channel.c:1587
at event-loop.c:122
0x7ffff4fb2ef2 <watch_func>, user_data=0x7fff980244e0) at giounix.c:166
0x7ffff86ec770) at gmain.c:3092
It is not used by spice-common, but both server and client can use it.
Compared to current checks in spice-gtk and spice server this macro only
supports libsasl2.
Acked-by: Christophe Fergeau <cfergeau@redhat.com>
libcacard.h requires 2.5.1. Keep compatibility for older versions until
the transition in distros to the standalone version is done.
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[ Christophe: add < 2.5.1 fallback ]
Signed-off-by: Christophe Fergeau <cfergeau@redhat.com>
This makes it possible to warn the developer that the GStreamer elements
needed at runtime are missing and give him a hint on how to fix the
issue.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
A call to SPICE_WARNING() anywhere in the configure file results in the
warning being printed at the end of the configure run where it will be
be visible. This makes it possible to keep the SPICE_WARNING() calls
together with the related feature checks instead of having to put a
separate AC_MSG_WARN() call near the end.
Signed-off-by: Francois Gouget <fgouget@codeweavers.com>
SPICE_CHECK_SMARTCARD documentation ends with a '-------' comment, but
the # to start the comment is missing, causing a warning message when
running configure.
GInetAddress is defined in gio, not glib. Not checking for gio-2.0 in
SPICE_CHECK_GLIB2 means gio won't be in GLIB2_LIBS, which causes link
errors when trying to build spice-server.
These macros were automatically appending the needed CFLAGS/LIBS to
variables passed as arguments. This is how spice-common uses them, but
now how spice-gtk/spice want to use them, and is making the macros more
complicated than they could (in particular this makes them use
AS_VAR_APPEND).
This is also not flexible enough as spice-gtk uses libcacard libraries,
while spice-common does not need them. If SPICE_CHECK_SMARTCARD
unconditionnally libcacard libraries to the variable spice-common passes
it as an argument, we'll end up linking with an unneeded library.
This commit removes this automatic appending from the SPICE_CHECK_*
macros and moves it to spice-common as it's the only one which needs it.
Now that spice-protocol ships the needed .proto files as well as the
corresponding python scripts, spice-common can use these in order to
generate the C code for the SPICE (de)marshallers.
After the patch adding support for python 3 to the code generator,
python-six is required when building from git. Since I got 2 different
reports of SPICE build failures right after introducing it, it's
probably better to check for the needed python modules from configure,
and exit with an error if they are missing.
This commit adds a --enable-python-checks configure flag for that
though, since we only want to do that when building from git. It assumes
that people running from git will be running autogen.sh, while people
building from tarballs will run configure.
A few files (the generated marshalling code and pixman-related utils)
make use of WORDS_BIGENDIAN in order to do the right thing depending on
endianness. configure.ac must call AC_C_BIGENDIAN for it to be defined.
Signed-off-by: Erlon R. Cruz <erlon.cruz@br.flextronics.com>
Signed-off-by: Rafael F. Santos <fonsecasantos.rafael@gmail.com>
Signed-off-by: Fabiano Fidêncio <Fabiano.Fidêncio@fit-tecnologia.org.br>
Signed-off-by: Erlon R. Cruz <erlon.cruz@br.flextronics.com>
Signed-off-by: Rafael F. Santos <fonsecasantos.rafael@gmail.com>
Signed-off-by: Fabiano Fidêncio <Fabiano.Fidêncio@fit-tecnologia.org.br>
