xeno-config(1)
| XENO-CONFIG(1) | Xenomai Manual | XENO-CONFIG(1) |
NAME
xeno-config - Retrieve Xenomai build flags and configuration
SYNOPSIS
xeno-config
xeno-config --v | --verbose
xeno-config --help
xeno-config --info
xeno-config --core
xeno-config --version
xeno-config [--cc] [--ccld] [--arch] [--prefix] [--posix|alchemy|rtdm|psos|vxworks|smokey] [--compat] [--auto-init|no-auto-init] [--auto-init-solib] [--mode-check|no-mode-check] [--cflags] [--ldflags] [--library-dir|libdir|user-libdir]
DESCRIPTION
xeno-config is a shell script which is aimed at retrieving the Xenomai build configuration data, such as the compiler and linker flags required for building applications. For this reason, xeno-config is typically used in Makefiles.
xeno-config --verbose dumps the build configuration data in a human-readable format.
Invoking xeno-config without any options is equivalent to running xeno-config --verbose --help.
OPTIONS
--v, --verbose
--help
--version
--cc
--ccld
--arch
--prefix
--[skin=]{posix, alchemy, rtdm, psos, vxworks, smokey, cobalt}
Note
--native and --skin=native are accepted for backward compatibility purpose. They are stricly equivalent to passing --alchemy --compat. Likewise, passing --rtdm or --skin=rtdm is stricly equivalent to passing --posix, enabling POSIX I/O routines to be wrapped to their respective Xenomai implementation.
Caution
Over Cobalt, only xeno-config --posix --ldflags (or --rtdm as an alias) returns the proper linker flags to cause POSIX routines invoked by the application to be wrapped to their respective Xenomai implementation. No other API will imply such wrapping. For this reason, --cobalt --ldflags should be used for linking exclusively against the Cobalt library (i.e. libcobalt.so) without symbol wrapping. Conversely, mentioning --posix along with other API switches with --ldflags will cause POSIX symbol wrapping to take place, e.g. use --posix --alchemy --ldflags for mixed API support with POSIX symbol wrapping.
--cflags
--ldflags
--library-dir, --libdir, --user-libdir
--auto-init, --no-auto-init
Building with --no-auto-init disables such initialization. In this case, the application code shall call the xenomai_init() routine manually, as part of its initialization chores on behalf on the main() routine, before any real-time service is invoked. See include/xenomai/init.h.
Note
This flag only makes sense when passed along with --ldflags.
--mode-check, --no-mode-check
The assertion failure is triggered if the calling thread has set the PTHREAD_WARNSW flag by a call to pthread_setmode_np().
By default, the mode checking routines are substituted to the original ones using the symbol wrapping mechanism also used for interposing on POSIX services. --no-mode-check disables such substitution.
These flags make sense when passed along with --ldflags only.
--auto-init-solib
The bootstrap code runs when the shared library is attached to a running executable, either because it appears in the static dependencies of this executable, or when loaded dynamically via the dlopen() interface.
--core
--compat
--info
ENVIRONMENT VARIABLES
DESTDIR
If the DESTDIR variable is set in the environment of xeno-config, its contents is prepended to all directory and file names based on the Xenomai installation root which may be output by the command.
If DESTDIR was set when installing Xenomai - typically after cross-compiling - DESTDIR must be set to the same value before calling xeno-config for accessing the target-based directories and files from the build system.
e.g.
$ configure --prefix=/usr --includedir=/usr/include/xenomai $ make install DESTDIR=/nfsroot/target $ DESTDIR=/nfsroot/target /nfsroot/target/bin/xeno-config --alchemy --cflags -I/nfsroot/target/usr/include/xenomai/cobalt -I/nfsroot/target/usr/include/xenomai -D_GNU_SOURCE -D_REENTRANT -D__COBALT__ -I/nfsroot/target/usr/include/xenomai/alchemy
EXIT STATUS
0
non-zero
| 2014/08/03 | Xenomai 3.1.2 |
