The Cygwin/X build has been broken for a long time, probably since modular X
This patch fixes up configure/makefile and some general build issues (#18568)
Signed-off-by: Jon TURNEY <jon.turney@dronecode.org.uk>
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.
This is done to actually change DIX_CFLAGS, as not all "modules" use
XORG_CFLAGS.
Also export the symbols that are required by other modules after
the change.
Note that it checks if support for symbol visibility is available by
the compiler, not if it is functional. It may have problems on non x86
architectures.
To disable the feature, just pass the option "--disable-visibility"
to the X Server configure script.
Unless using an alternate build schema, drivers built from a git
checkout will use the same "visibility" related CFLAGS used to compile
the X Server.
pixman 0.13.2 now holds all of the matrix operations. This leaves
the protocol conversion routines and some ABI stubs in place
Signed-off-by: Keith Packard <keithp@keithp.com>
Added a configure option called --enable-standalone-xpbproxy which is useful for deveoping xpbproxy.
The 'active' switch in preferences just disables the in-server xpbproxy (not this standalone).
(cherry picked from commit 4294493632)
Really, this was a bad idea. It's not security, the UI features that would
have been cool (e.g. clicking through windows) aren't implemented anyway, and
there's nothing you can't achieve just by using plain XI anyway.
Requires inputproto 1.9.99.6.
There is no way this code can have been building for anyone since pciaccess
was merged. BSD and Linux were already using OS code on sparc, the only
people who could want this are Solaris, who should be using pciaccess
anyway.
Readded the old exec() server startup path for regression testing.
Don't use the dynamic fd addition code since it's not quite working correctly.
(cherry picked from commit 08f3fe153e)
Us shipping a GUI configuration utility (especially as part of the
server!) was pretty pointless. There was pretty much nothing it could
configure which wasn't already runtime adjustable: if you could get a
server up with functioning input and output, there wasn't much xorgcfg
could do for you.
Au revoir.
Fix and marginally simplify the SHA1 handling. First, we allow people
to override it. Secondly, we try for libmd. Then, we try for OpenSSL
with pkg-config. In a last, desperate move, we try libcrypto on its
own. This allows the server to, y'know, _link_ when using OpenSSL,
instead of failing because we only have -lcrypto, and not -lssl.
Previously, the code was using PKG_CHECK_EXISTS before PKG_CHECK_MODULES,
(to cater to OpenBSD systems that include openssl by default but without
a .pc file). But this meant that systems that didn't have openssl installed
at all would not get any error message at configure time.
Now, if the SHA1_Init function is found in -lcrypto without any additional
flags, then that's used. Otherwise, pkg-config is used to find the right
flags to link against libcrypto. And if that fails, a nice error message
is now generated.
Some reasons to embed fonts by default:
1. X server doesn't pick a good default font path so it's easiest just
to built in the core fonts and let new X hackers more happy. Developers
and distro guys are wise enough to just set --disable-builtin-fonts
when they want.
2. Seems that this is by far the most popular FAQ
(http://www.x.org/wiki/FAQErrorMessages).
3. No one gave a good argument to not do this:
http://lists.freedesktop.org/archives/xorg/2008-May/035479.html
This code hasn't been updated with anything even resembling what anyone is
shipping in nearly thirty months. It hasn't built out of the box since
7.1. Most of its features over AIGLX are accomplished with DRI2 and
friends.
This copies over the files generated from mesa/src/mesa/glapi. There's
a corresponding mesa commit that makes it easy to generate the glapi files
straight into the xserver tree when the XML definitions change.
The only few files that are copied from mesa but aren't generated are
glapi.[ch] and glthread.[ch]. Everything in there is technically DRI
driver API and the whole setup is still a bit fragile, but it's not a new
problem.
The --with-mesa-source configure option is still around since other
parts of the server (XGL and DMX - grep for MESA_SOURCE) need that,
but for common case of building with GLX and AIGLX support, that
option is no longer needed.
Conflicts:
Xext/xprint.c (removed in master)
config/hal.c
dix/main.c
hw/kdrive/ati/ati_cursor.c (removed in master)
hw/kdrive/i810/i810_cursor.c (removed in master)
hw/xprint/ddxInit.c (removed in master)
xkb/ddxLoad.c
