As with other in-tree users avoid -L + -l.
This avoids any confusion with versions of these libraries already
installed on the system and the possibility of linking against them by
mistake.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Some systems have python-config include -D_FORTIFY_SOURCE in the
CFLAGS. But -D_FORTIFY_SOURCE does not (currently) work with -O0, and
-O0 is enabled in debug builds (since 1166ecf781). As a result, on
those systems, debug builds fail.
Work around this problem as follows:
* In configure, detect -D_FORTIFY_SOURCE in $(python-config --cflags)
* If detected, set the new autoconf substitution and make variable
PY_NOOPT_CFLAGS to -O1.
* In tools/Rules.mk, where we add -O0, also add PY_NOOPT_CFLAGS
(which will override the -O0 with -O1 if required).
Overriding the -O0 is better than disabling Fortify because the
latter might have an adverse security impact. A user who wants to
disable optimisation completely even for Python and also disable
Fortify can set the environment variable
EXTRA_CFLAGS_XEN_TOOLS='-U_FORTIFY_SOURCE -O0'
Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Reported-by: Jan Beulich <JBeulich@suse.com>
Signed-off-by: Jan Beulich <jbeulich@suse.com>
CC: Jan Beulich <JBeulich@suse.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Euan Harris <euan.harris@citrix.com>
CC: Wei Liu <wei.liu2@citrix.com>
CC: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Tested-by: Don Slutz <dslutz@verizon.com>
The original rule to target "distclean" in tools/Rules.mk was in effect
"make clean". It should be "make distclean".
However not all Makefiles in subdirectories have distclean target
defined. So this patch also adds a bunch of distclean targets to various
Makefiles. They only depend on clean target and don't have any actions
in most cases.
With the patch applied, following command outputs 0 results:
find tools -name 'Makefile*' -exec grep -L 'distclean' {} \+ \
| grep -v ocaml | grep -v libfsimage
Ocaml and libfsimage are known to have distclean defined in a dedicated
rules file.
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Tools debug builds are built with optimization level -O1, inherited from
the CFLAGS definition in StdGNU.mk. Optimizations confuse the debugger,
and the comment justifying -O1 in StdGNU.mk should not apply for a
userspace library. Disable optimization by appending -O0 to CFLAGS,
which overrides the -O1 flag specified earlier.
Also specify -g3, to add macro debugging information which allows
gdb to expand macro invocations. This is useful as libxl uses many
non-trivial macros.
Signed-off-by: Euan Harris <euan.harris@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- inserted a clarifying "enable" into comment ]
Also moves xc_dom.h to include as it is used often by other xen tools.
Use the new include subdirectories to build Xen tools, qemu-xen and
stubdoms.
Add the old libxc include path to the programs that need it to build,
on a case by case basis and commeting that they shouldn't require
internal libxc headers to build.
[ And: update QEMU_TRADITIONAL_REVISION to corresponding qemu patch
- Ian jackson ]
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Autoconf already has appropriate Linux/non-Linux logic for CONFIG_BLKTAP2.
Let LIBXL_BLKTAP inherit directly from CONFIG_BLKTAP2, rather than requiring a
further LIBXL_BLKTAP=n in addition to ./configure --disable-blktap2 to get
libxl to successfully link under Linux.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
CC: Ian Campbell <Ian.Campbell@citrix.com>
CC: Ian Jackson <Ian.Jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Since it may not exist when doing e.g. "make clean". There is
existing logic in the makefiles which will raise an error if an
actual build target is invoked without having run configure.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: Luis R. Rodriguez <mcgrof@do-not-panic.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
This moves all generic path variables to a new the config/Paths.mk.in
input source file to be processed at configure time, tons of files use
these so this just share them. This also paves the way to let us
easily dynamically configure these with autoconf, for now we leave the
same presets as was present before.
This work was prompted by looking for an autoconf way to do
replacements for the hotplug global file, while at it I realized
that a few other files use the same variables and have in places
around the tree the same constructs for generating their own
files. This makes use of the old buildmakevars2file() but generalizes
the definition of the paths at configure time and spreads the
new definitions out throughout the build system.
This has no impact on building the hypervisor and extras/mini-os,
you do not need to, and are not expected to, run configure to build
those targets.
While at it lets add some documentation on the for the two files on
the source file, we can expand further details on the wiki [0].
[0] http://wiki.xen.org/wiki/Category:Host_Configuration#System_wide_xen_configuration
Cc: Ian Campbell <ian.campbell@citrix.com>
Cc: Ian Jackson <ian.jackson@eu.citrix.com>
Cc: Samuel Thibault <samuel.thibault@ens-lyon.org>
Cc: Jan Beulich <jbeulich@suse.com>
Cc: Keir Fraser <keir@xen.org>
Cc: Tim Deegan <tim@xen.org>
Signed-off-by: Luis R. Rodriguez <mcgrof@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
[ ijc -- reran autogen.sh ]
Introduce a new build variable "nosharedlibs".
In tools/libxc use it instead of $(stubdom).
In tools/xenstore honour it, and build static clients.
If shared libs are disabled, do not try to install or symlink them.
Set nosharedlibs when building for MiniOS or NetBSDRump.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <Ian.Campbell@citrix.com>
---
v2: Clarify deliberate INSTALL_SHLIB and SYMLINK_SHLIB breakage.
This variable is the suffix to use for finding libraries when doing
compile-time linking. For now we always set it to ".so" - so no
functional change.
In a forthcoming patch it may take on different values.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
INSTALL_SHLIB is like INSTALL_PROG but used only for shared libraries.
SYMLINK_SHLIB is the ln -sf rune for shared library symlinks.
Use these in the appropriate places in tools/libxc and tools/xenstore.
No functional change right now. In a forthcoming patch these
variables might take on different values.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
In principle it would be possible to make a rumpuser-xen-based stub
xenstored, but all the necessary pieces do not yet exist.
So provide a facility to disable compilation of xenstored, and use it
to disable it on rump kernels.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
There is a small set of places where files in subdirectories get
compiled from the parent directory. Dependency file wise this is no
problem as long as the files use names distinct without regard to the
directories they sit in, and tools/console/ violates this (in having
two main.c files). Hence we need to avoid losing the directory name,
both to ensure the two compiler instances don't simultaneously write
to the same file (happening of which is what triggered me looking
into this) and to guarantee dependencies for all files will be seen
by make on an incremental rebuild.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
getconf is not cross-compile friendly since it reports the features of the host
and not the target. There doesn't appear to be a $triplet-getconf.
AC_SYS_LARGEFILE arranges for #defines to appear in config.h however Xen's
build system expects these to be part of C{PP}FLAGS. Since I'm not confident
that everything in Xen includes config.h I instead arrange for the result of
running AC_SYS_LARGERFILE to end up in CFLAGS.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Centralise the version check in Config.mk. Any more strict version
requirements can be added to specific subdirs/arches.
Signed-off-by: Keir Fraser <keir@xen.org>
For build systems which build certain Xen components separately, allow certain
components to be conditionally built based on .config, rather than always
building them.
This patch allows qemu and blktap to be configured in this manner.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Tools.mk should be included first, or PREFIX is not honoured in the
other conf/ files that define the paths of several tools.
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Campbell <ian.campbell@citrix.com>
Currently qemu-xen will be compiled with CFLAGS only if CFLAGS was
already in the environment during make invocation. If CFLAGS is in
environment then make will append all of the various flags specified in
xen Makefiles to this environment variable, which is then used in qemu
configure. Since qemu-xen is not ready for compiler flags like
"-std=gnu99" compilation will fail. If CFLAGS is not in environment,
then configure will use just its own "-O2 -g" because make does not
export its own CFLAGS variable.
>From a distro perspective, it is required to build libraries and
binaries with certain global cflags (arbitrary gcc options). Up to the
point when qemu-xen was imported it worked as expected by exporting
CFLAGS before 'make tools'. Now qemu-upstream reuses these CFLAGS, but
it cant deal with the result.
This patch extends the tools Makefiles so that three new environment
variables are recognized:
EXTRA_CFLAGS_XEN_TOOLS= specifies CFLAGS for the tools build.
EXTRA_CFLAGS_QEMU_TRADITIONAL= specifies CFLAGS for old qemu.
EXTRA_CFLAGS_QEMU_XEN= specifies CFLAGS for new qemu.
Special care needs to be taken in tools/firmware because the resulting
binaries are not linked with the hosts runtime libraries. These binaries
run in guest context. To avoid build errors from gcc options like
-fstack-protector, reuse existing practice to unset the new
EXTRA_CFLAGS_XEN_TOOLS for the firmware dirs.
The new feature can be used like this in a rpm xen.spec file:
export EXTRA_CFLAGS_XEN_TOOLS="${RPM_OPT_FLAGS}"
export EXTRA_CFLAGS_QEMU_TRADITIONAL="${RPM_OPT_FLAGS}"
export EXTRA_CFLAGS_QEMU_XEN="${RPM_OPT_FLAGS}"
./configure \
--libdir=%{_libdir} \
--prefix=/usr
make
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
distclean removed config/Tools.mk which was needed by tools/Rules.mk, thus
preventing distclean from running properly in the tools directory. This patch
only enforces config/Tools.mk presence when not performing a clean/distclean
target
Signed-off-by: Roger Pau Monne <roger.pau@citrix.com>
Cc: George Dunlap <george.dunlap@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Added autotools magic to replace custom check scripts. The previous
checks have been ported to autoconf, and some additional ones have
been added (plus the suggestions from running autoscan). Two files are
created as a result from executing configure script, config/Tools.mk
and config.h.
conf/Tools.mk is included by tools/Rules.mk, and contains most of the
options previously defined in .config, that can now be set passing
parameters or defining environment variables when executing configure
script.
config.h is only used by libxl/xl to detect yajl_version.h.
[ tools/config.sub and config.guess copied from
autotools-dev 20100122.1 from Debian squeeze i386,
which is GPLv2.
tools/configure generated using the included ./autogen.sh
which ran autoconf 2.67-2 from Debian squeeze i386. autoconf
is GPLv3+ but has a special exception for the autoconf output;
this exception applies to us and exempts us from complying
with GPLv3+ for configure, which is good as Xen is GPL2 only.
- Ian Jackson ]
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Tested-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <Ian.Jackson@eu.citrix.com>
Create two new variables called APPEND_ and PREPEND_ to add compile
flags at the beginning or at the end of the search path.
Added a new semantic for user defined compile flags, here is the list
of possible options:
PREPEND_LIB: add libraries to the search path before xen
(before xen installation folders).
PREPEND_INCLUDES: add headers to the search path before xen
(before xen installation folders).
APPEND_LIB: add libraries to the search path at the end
(after all xen installation folders have been added).
APPEND_INCLUDES: add libraries to the search path at the end
(after all xen installation folders have been added).
EXTRA_INCLUDES and EXTRA_LIB can still be used, and they will have the
same effect as PREPEND_INCLUDES and PREPEND_LIB.
Signed-off-by: Roger Pau Monne <roger.pau@entel.upc.edu>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This library implements a bidirectional communication interface between
applications in different domains, similar to unix sockets. Data can be
sent using the byte-oriented libvchan_read/libvchan_write or the
packet-oriented libvchan_recv/libvchan_send.
Channel setup is done using a client-server model; domain IDs and a port
number must be negotiated prior to initialization. The server allocates
memory for the shared pages and determines the sizes of the
communication rings (which may span multiple pages, although the default
places rings and control within a single page).
With properly sized rings, testing has shown that this interface
provides speed comparable to pipes within a single Linux domain; it is
significantly faster than network-based communication.
Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
This completely removes libxenstore from libxl users' view.
xl still needs libxenctrl directly due to the direct use of the
xentoollog functionality but it is not exposed to the indirect linkage
anymore.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Tested by forcing --as-needed via tools/Rules.mk but this is included
since the intention is simply to support diustros which default to
--as-needed, not to enable it everywhere.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
In particular if binary A uses libB and libB uses libC entirely
internally then A does not need to link against libC only libB.
However when linking binary A the linker does need to have visibility
of the libraries which libB links against (libC in this example). For
out of tree uses this is achieved without fuss due because the
libraries are installed in a standard path. However in the case of
in-tree users the linker needs a hint in the form of the -rpath-link
option. Therefore a new class of build variable, $(SHLIB_FOO), is
introduced which includes the linker options needed to link against a
library which uses libFOO. The intention is that $(LDLIBS_bar) will
include the $(SHLIB_foo)s which it uses where necessary rather
requiring that users are aware of this.
For the python extensions this change appears particularly large since
previously each of python bindings were linked against the union of
all possible libraries used by all bindings instead of just what they
individually needed.
This change removes a dependency on libdl.so from nearly everything
in the system, only libxenctrl actually uses it.
In the context of xl/libxl the intention of libxl is to remove any
need for a user of libxl to know about libxenstore or libxenctrl,
however in the current build it is xl which links against those
libraries rather than libxl (which only links against libc). After
this change libxl correctly depends on the libraries it uses and xl
does not depend on libraries which it is not support to be required to
know about. Note that xl does depend on libxenctrl.so since it uses
xtl_* directly.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
The Xen build system is not currently compatible with the --as-needed
linker option. The proper fix for this is turning out to be rather
invasive to the build system so simply disable for now with the
intention of revisiting for the 4.2 release.
The --no-as-needed option is available at least since binutils 2.15
(released in May 2004) and hence I think can be unconditionally relied
on.
Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Reported-by: Nathan March <nathan@gt.net>
Tested-by: Nathan March <nathan@gt.net>
Committed-by: Ian Jackson <ian.jackson@eu.citrix.com>
Linker command lines are order-sensitive.
Move linker options -Lfoo -lfoo from LDFLAGS to LDLIBS and place this new
variable after the objects to link. This resolves build errors in xenpagin
and blktap with recent toolchains.
rename SHLIB_CFLAGS to SHLIB_LDFLAGS
rename LDFLAGS_* to LDLIBS_*
move LDFLAGS usage after CFLAGS in CC calls
remove stale comments in xenpaging Makefile
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Acked-by: Ian Jackson <ian.jackson@eu.citrix.com>
Revert
df9d8319bd37 Fix blktap2 NetBSD build and also revert broken change
e76befc7fe2d portability fixes from tools/console
24277e3237ca Fix linking error when creating the xl binary.
Now it builds again.
to make libxl build on NetBSD.
blktapctl is build on Linux only. This will be another patch to finally
unbreak libxl.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
Doesn't work when build-time python path differs from install-time. Do
we care about this given tools should be packaged/built for the
specific run-time distro?
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
pygrub currently has a hardcoded path of /usr/bin/python which is not
correct if the version of python at install time is not the same as
that at build time. This patch uses the existing install-wrap and
python/get-path machinery.
(It does not address the currently-existing bug that the get-path
machinery works by assuming that `python' is a symlink, rather than
querying the python interpreter for its version.)
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
Remove *all* hardcoded "/etc/xen" strings in python code.
Additionally, it removes pygrub_path from osdep.py. Its use has been
replaced with auxbin.pathTo("pygrub").
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>
For now hardcode /etc w/o a prefix as there are hardcoded
config paths in the code which would break otherwise.
Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>