In order to use libxf86config in a shared library, all the code must be
compiled with -fPIC. Add proper PIC support for libxf86config by turning
it into a libtool library. However, since we don't want to guarantee API
or ABI stability, make sure it's only built static.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Acked-by: Gaetan Nadon <memsize@videotron.ca>
https://bugs.freedesktop.org/show_bug.cgi?id=32436
Fix typo introduced in 2416255f7e that breaks builds when
configured --enable-install-libxf86config
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Julien Cristau <jcristau@debian.org>
Tested-by: Simon Thum <simon.thum@gmx.de>
Requires linking xprintf.c into libxf86config for those who build it.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Mikhail Gusarov <dottedmag@dottedmag.net>
We could just use $projectroot/etc and $projectroot/share, but the user
might have other plans for them.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
Currently Xorg uses hal's fdi files to decide what configuration options
are applied to automatically added input devices. This is sub-optimal
since it requires users to use a new and different configuration store
than xorg.conf.
The InputClass section attempts to provide a system similar to hal where
configuration can be applied to all devices with certain attributes. For
now, devices can be matched to:
* A substring of the product name via a MatchProduct entry
* A substring of the vendir name via a MatchVendor entry
* A pathname pattern of the device file via a MatchDevicePath entry
* A device type via boolean entries for MatchIsKeyboard, MatchIsPointer,
MatchIsJoystick, MatchIsTablet, MatchIsTouchpad and MatchIsTouchscreen
See the INPUTCLASS section in xorg.conf(5) for more details.
Signed-off-by: Dan Nicholson <dbn.lists@gmail.com>
Reviewed-by: Peter Hutterer <peter.hutterer@who-t.net>
We were generating a shared library, but this lib is foobar, the parser
requires some symbols from the X server or from the program its being linked
into. If the program its being linked into (say a python .so) has symbol
visibility enabled then it will fail to dynamic link, also if this .so has
symbol visiblity enabled it will fail to dynamic link.
Screw it go back to a .a file really unless someone cleans it up properly.
Signed-off-by: Dave Airlie <airlied@redhat.com>
All .a libraries were converted to .la, and instead of linking the
Xorg binary with a mix of .a and .la, and adding some libraries more
then once in the command line, etc, now it generates a single libxorg.la
from all the required convenience libraries, and links with a dummy
xorg.c (that should usually be the file with the main function...).
This removes the requirement of some things like libosandcommon and
libinit, that existed to circumvent problems when linking multiple
.a and .la in the final Xorg binary.
The "symbol table" is now generated dynamically, by a shell script,
with an embedded gawk parser that parses cpp output. The new file
sdksyms.sh is generated by hand by analyzing all Makefile.am's and
making it create a sdksyms.c file, that includes all sdk headers that
will add symbols for the Xorg binary. Module headers aren't read, and
a in 2 files it was required to add a "<hash>ifndef XorgLoader" around
declarations shared between the Xorg binary and libextmod. A few
other changes were added to other sdk headers, like preventing
multiple inclusion, or including other headers to satisfy dependencies.
This should be a lot more portable, and better (hopefully properly)
using libtool to generate convenience libraries.
New modes header files required a few minor changes to be used by external
drivers, the most notable of which is the publication of the config file
parser header files.
CFLAGS is a user variable, extracted from the environment at configure time
and settable by the user at build time. We must not override this variable.