Calling ./configure with python3 being there but no python,
tools/configure will fail. Fix that by defaulting to python and
falling back to python3 or python2.
While at it fix the use of non portable "type -p" by replacing it by
AC_PATH_PROG().
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wl@xen.org>
[ wei: run autogen.sh ]
Reviewed-by: Ian Jackson <ian.jackson@eu.citrix.com>
(cherry picked from commit 5852ca4852)
https://docs.python.org/3.8/whatsnew/3.8.html#debug-build-uses-the-same-abi-as-release-build
> To embed Python into an application, a new --embed option must be
> passed to python3-config --libs --embed to get -lpython3.8 (link the
> application to libpython). To support both 3.8 and older, try
> python3-config --libs --embed first and fallback to python3-config
> --libs (without --embed) if the previous command fails.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Acked-by: Wei Liu <wl@xen.org>
[ wei: rerun autogen.sh ]
The pvshim can only be built 64-bit because the hypervisor is only
64-bit nowadays. The hypervisor build supports XEN_COMPILE_ARCH and
XEN_TARGET_ARCH which override the information from uname. The pvshim
build runs out of the tools/ directory but calls the hypervisor build
system.
If one runs in a Linux 32-bit userland with a 64-bit kernel, one used
to be able to set XEN_COMPILE_ARCH. But nowadays this does not work.
configure sees the target cpu as 64-bit and tries to build pvshim.
The build prints
echo "*** Xen x86/32 target no longer supported!"
and doesn't build anything. Then the subsequent Makefiles try to
install the non-built pieces.
Fix this anomaly by causing configure to honour the Xen hypervisor way
of setting the target architecture.
In principle this user behaviour is not handled quite right, because
configure will still see 64-bit and so all the autoconf-based
architecture testing will see 64-bit rather than 32-bit x86. But the
tools are in fact generally quite portable: this particular location
in configure{.ac,} is the only place in tools/ where 64-bit x86 is
treated differently from 32-bit x86, so the fix is sufficient and
correct for this use case.
It remains the case that XEN_COMPILE_ARCH or XEN_TARGET_ARCH to a
non-x86 architecture, when configure thinks things are x86, or vice
versa, will not work right.
(This is a bugfix to 8845155c83
pvshim: make PV shim build selectable from configure
which inadvertantly deleted the logic to only build the shim for
XEN_TARGET_ARCH != x86_32.)
I have rerun autogen.sh, so this patch contains the fix to configure
as well as the source fix to configure.ac.
Fixes: 8845155c83
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
CC: Olaf Hering <olaf@aepfle.de>
CC: Roger Pau Monné <roger.pau@citrix.com>
Release-acked-by: Jürgen Groß <jgross@suse.com>
Reviewed-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Wei Liu <wl@xen.org>
./configure takes a PYTHON=... argument. You can use this to specify
the python interpreter. However, for no good reason, it expects an
absolute path.
Fix this. The new logic is:
* if not set, default to `python'
* if not absolute, look it up with type -p
* split into directory and executable name
The results in config/Tools.mk (which contains @PYTHON@ and
@PYTHONPATH@) are identical for both
./configure
./configure PYTHON=/usr/bin/python
so I assert this has no functional change except that now you can say
./configure PYTHON=python
In particular you can now say
./configure PYTHON=python2
./configure PYTHON=python3
The latter is useful if you want python3 (which should probably be the
default, but does not work right now). The former is useful if you
want python2 but your distro has foolishly made "python" refer to
python3.
CC: Doug Goldstein <cardoe@cardoe.com>
CC: George Dunlap <george.dunlap@citrix.com>
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Wei Liu <wl@xen.org>
Blktap2 is effectively dead for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. libxl no longer supports TAP disk backend, with appropriate assertions
added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend
3. Remove blktap2 entry from MAINTAINERS
A patch to remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
So a user can decide whether to compile a PV shim as part of the tools
build. Note that the default behavior is preserved, which is to build
a PV shim when the target or host (if target is unset) architecture is
64bit x86.
Requested-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.s ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
It is common that build hosts are isolated from outside world. They
don't necessarily have wget or ftp installed.
Turn the error into warning in configure. And point FETCHER to `false'
command if neither wget nor ftp is available, so any attempt to
download will result in error.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Do the following:
1. Change the form of "print".
2. Use AC_CHECK_FUNC to avoid the need to generate library name.
3. Remove unused stuff.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Reviewed-by: Anthony PERARD <anthony.perard@citrix.com>
CentOS 5, which was the reason for the 2.4 restriction, is EOL. CentOS
6 ships 2.6.
Bump the version to 2.6 in README. Update configure.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
9pfs support has been a documented feature since Xen 4.9, but QEMU will
not be built with backend support unless VirtFS is enabled, which is
predicated on the libcap and libattr dev packages being installed. This is
not obvious to anyone intending to use 9pfs.
This patch adds an 'enable-9pfs' option to configure which, if specified,
will cause '--enable-virtfs' to be passed to QEMU's configure. This will
cause the dependency on libcap and libattr to be called out if the packages
are not in installed.
For completeness, specifying 'disable-9pfs' will cause '--disable-virtfs' to
be passed to QEMU's confgure and not specifying an option will keep the
previous behaviour of predicating VirtFS on whether the libcap and libattr
packages are installed.
Signed-off-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Wei Liu <wei.liu2@citrix.com>
It appears that the test in 01d631028 for ipxe's dependency on rombios
is not good enough. Configuring with --disable-rombios doesn't disable
ipxe.
Fix it by testing the dependency after AC_ARG_ENABLE and AC_ARG_WITH
have taken effect.
At the same time, regularise options for ipxe:
--enable-ipxe enable building in-tree ipxe
--disable-ipxe disable building in-tree ipxe
--with-system-ipxe specify a path to be baked into code, disable
building in-tree ipxe, this trumps --{en,dis}able-ipxe
--without-system-ipxe error
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
The paths shouldn't be set to "yes". We ask the user to set absolute
paths because Xen's build system doesn't know where to search, and the
build machine doesn't necessarily have those binaries present in the
first place.
Reported-by: Anthony Perard <anthony.perard@citrix.com>
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This option lets user specify which binary is to be used as ipxe. If
it is specified, the in-tree ipxe will not be built. This option is in
line with other --with-system-* options we provide.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Allow the path to be set from a configure command line option.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh ]
Curl and xml2 are not required anymore since 185bb58be3 ("tools: drop
libxen") removed their only user.
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh ]
The ocaml safe-strings patch uses code introduced in ocaml 4.02
so update the minimal version.
Signed-off-by: Michael Young <m.a.young@durham.ac.uk>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Config.mk
MINIOS_UPSTREAM_REVISION } changed from tag to equivalent
QEMU_TRADITIONAL_REVISION } specific commit hash
QEMU_UPSTREAM_REVISION now tracking master again
README, xen/Makefile
Update version number
*/configure
Reran autoconf; only change is version number
tools/Rules.mk, xen/Kconfig.debug
Enable debug.
Reverts 229ff3125b "Use non-debug build for Xen 4.9".
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
If ocaml.m4 didn't find ocamlopt, disable all the ocaml builds.
Currently our Makefiles do not work properly when the native code
compiler (`ocamlopt') is not available. In principle this should be
fixed to fall back to bytecode, but this is not a task for this stage
of the Xen 4.9 release.
Without this change, we cannot build on systems with only ocamlc.
That includes Debian jessie ARM64, as used on the new ARM64 hardware
in the Xen Project CI test lab.
When the Makefiles are fixed, this commit should be reverted.
Committers: Please rerun autogen.sh.
CC: Julien Grall <julien.grall@arm.com>
CC: Christian Lindig <christian.lindig@citrix.com>
CC: Jonathan Ludlam <Jonathan.Ludlam@citrix.com>
CC: David Scott <dave@recoil.org>
CC: Wei Liu <wei.liu2@citrix.com>
Tested-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Instead of generating the *.pc.in files at configure time use the new
pkg-config scheme for those files. Add the dependencies to other Xen
libraries as needed.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
There have been reports that Fedora 25 uses /run instead of /var/run.
Add a --with-rundir option ito configure to be able to specify that
directory. Default is still /var/run.
A re-run of autogen.sh is required.
Signed-off-by: Juergen Gross <jgross@suse.com>
[ wei: run autogen.sh ]
Acked-by: Wei Liu <wei.liu2@citrix.com>
This seems to be looking for a function MD5. But nothing uses it.
The build works fine if this is disabled and libcrypto is not
installed.
This check was first introduced in 68a3e1e873 "[TOOLS] Add more
checks for devel packages." in 2006. At that time -lcrypto was used
by tools/blktap/ and tools/vtpm_manager/, which are both gone now.
Signed-off-by: Ian Jackson <ian.jackson@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
We upgraded ipxe in 38ab99b2 ("ipxe: update to new commit"). That
version of ipxe requires liblzma to build.
Check that in configure and document this in README.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
It uses static DSDT table like the way x86 uses. Currently the DSDT
table only contains processor device objects and it generates the
maximal objects which so far is 128.
While the GUEST_MAX_VCPUS is defined under __XEN__ or __XEN_TOOLS__, it
needs to add -D__XEN_TOOLS__ to compile mk_dsdt.c.
Also only check iasl for aarch64 in configure since ACPI on ARM32 is not
supported.
Signed-off-by: Shannon Zhao <shannon.zhao@linaro.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: run autogen.sh and fix compilation on x86 ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Currently configure code doesn't define {SEABIOS/OVMF}_PATH when
--with-system-{ovmf/seabios} is used. Fix this by making sure those
defines are always set if the internal {ovmf/seabios}_path variables are
also set.
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Suggested-by: Wei Liu <wei.liu2@citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
[ wei: run autogen.sh ]
Acked-by: Wei Liu <wei.liu2@citrix.com>
Blktap2 is effectively dead code for a few years.
Notable changes in this patch:
0. Unhook blktap2 from build system
1. Now libxl no longer supports TAP disk backend, appropriate assertions
are added and some code paths now return ERROR_FAIL
2. Tap is no longer a supported backend in doc
3. Remove relevant entries in MAINTAINERS
A patch to actually remove blktap2 directory will come later.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: George Dunlap <George.Dunlap@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
... to compile SeaBIOS and OVMF. Only depend on CONFIG_*.
If --with-system-* configure option is used, then set *_CONFIG=n to not
compile SEABIOS and OVMF.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Those paths are to be used by libxl, in order to load the firmware in
memory. If a system path is not defined via --with-system-seabios or
--with-system-ovmf, then default to the Xen firmware directory.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
In order to prepare starting a xenstore domain split out the starting
of the xenstore daemon from the xencommons script into a dedicated
launch-xenstore script.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
On a system with systemd the xenstore sockets are created via systemd.
Remove the related configuration files in order to be able to decide
at runtime whether the sockets should be created or not. This will
enable Xen to start xenstore either via a daemon or via a stub domain.
As the xenstore domain start program will exit after it has done its
job prepare the same behaviour to be tolerated by systemd for the
xenstore daemon by specifying the appropriate flags in the service
file.
A rerun of autogen.sh is required.
Signed-off-by: Juergen Gross <jgross@suse.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: David Scott <dave@recoil.org>
A dedicated Xen driver domain init service starts "xl devd" in domU. But
currently, it is only supplied in the form of a SysV init script, which
systemd users run through a backward compatiblity wrapper automatically
generated by systemd-sysv-generator. This patch adds a (naturally more
lightweight) native systemd unit to be used instead.
The xendriverdomain service is only relevant to domU, but should not run
in dom0. Therefore, the systemd unit uses "ConditionVirtualization=xen",
which evaluates to true in domU and (since systemd version 214, released
on 2014-06-11) to false in dom0. Users or distributors who need to be
compatible with even older systemd versions, but still want to prevent
"xl devd" startup in dom0, could add the following line in [Service]:
ExecStartPre=/bin/sh -c "! grep -q control_d /proc/xen/capabilities"
(Please rerun autogen.sh after applying this patch)
Signed-off-by: Rusty Bird <rustybird@openmailbox.org>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Wei Liu <wei.liu2@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: rerun autogen.sh ]
It defaults to /var/run/xenstored. It will be used later to remove some
hard-coded paths in tree. There should be no visible change to default
configuration.
Install and remove it in respective Makefile targets.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This variable defaults to /var/lib/xen. It will be used to substitute
various hard-coded paths in tools.
The new variable points to $localstatedir/lib/xen, which defaults to
/var/lib/xen, so there is no change in default configuration.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Generate oxenstored.conf with configure. This involves modifying
tools/configure.ac and rerun autogen.sh.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
In 936a7a54 ("Open Xen 4.8-unstable), output of autogen.sh was not
included. The configure scripts still referred to 4.7.
Run autogen.sh and commit the result.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
From systemd change log, since version 209, libsystemd.so contain
everything, including libsystemd-daemon.so. Distro may, or may not provide
the compatibility libraries which libsystemd-daemon is part of.
So, if libsystemd-daemon is not available, check for the presence of
a recent enough libsystemd.
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
[ wei: run autogen.sh ]
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>