Annotation of xenocara/README, Revision 1.20
1.1 matthieu 1:
2: Notes on building Xenocara for OpenBSD X hackers
3:
4: This document presents some techniques that can be useful for people
5: wanting to hack the xenocara tree. It assumes some basic knowledge of
6: the OpenBSD build system, as described in the release(8) manual page.
7:
8: o About Xenocara
9: --------------
1.11 david 10: Xenocara is the name chosen for OpenBSD's version of X. It's
1.1 matthieu 11: currently based on X.Org 7.2 and its dependencies. The goal of
12: Xenocara is to provide a framework to host local modifications and to
13: automate the build of the modular X.Org components, including 3rd
1.11 david 14: party packages and some software maintained by OpenBSD developers.
1.1 matthieu 15:
16: o Source tree
17: -----------
18:
19: The organisation of the xenocara directory follows the general
20: organisation used in X.Org:
21:
22: - app: X applications and utilities
23: - data: various data files (keyboard mappings and bitmaps)
24: - doc: documentation
25: - driver: input and video drivers
26: - font: fonts
27: - lib: libraries
28: - proto: X protocol headers
29: - util: utilities that don't fit anywhere else
30: - xserver: the source for the X servers
31:
32: In addition Xenocara uses the following directories:
33:
34: - dist: contains the Mesa sources, shared by lib and xserver above
35: - distrib: all binary distribution related tools and data
36: - etc: mtree(8) data files
1.3 matthieu 37: - share: make(1) configuration for Xenocara
1.1 matthieu 38:
1.2 matthieu 39: At the top-level directory two files describe the individual
1.3 matthieu 40: components of Xenocara:
1.1 matthieu 41:
1.2 matthieu 42: - MODULES lists all X.Org components (imported from the X.Org
43: distribution at http://xorg.freedesktop.org/archive/)
1.3 matthieu 44: - 3RDPARTY lists all 3rd party software components provided in Xenocara,
1.2 matthieu 45: either as dependencies of the X.Org software, or as
46: complements to it to provide a more useable default
47: environment.
48:
49: o Compiling and installing
50: ------------------------
51:
1.3 matthieu 52: Xenocara is made up of more than three hundred different
1.20 ! jolan 53: independent packages that need to be built and installed in the right
1.3 matthieu 54: order, especially while bootstrapping (while /usr/X11R6 is still
55: empty). The Xenocara Makefiles take care of that using the 'build'
1.2 matthieu 56: target.
57:
1.5 matthieu 58: Quick startup guide
59:
60: The following steps will build and install everything for the first time.
61:
1.7 matthieu 62: cd xenocara
1.5 matthieu 63: make bootstrap
64: make obj
65: make build
66:
67: If you want to use another obj directory see below.
68:
1.2 matthieu 69: Requirements
70:
71: A freshly checked out xenocara tree is buildable without any external
72: tool. However if you start modifying things in the automake build
73: system used by many packages, you will need to have the following
1.3 matthieu 74: GNU autotools packages installed:
1.2 matthieu 75:
76: - automake 1.9 (devel/automake/1.9)
77: - autoconf 2.59 (devel/autoconf/2.59)
1.6 matthieu 78: - metaauto 0.6 (or later) (devel/metaauto)
1.2 matthieu 79: - libtool 1.5.22 (or later) (devel/libtool)
80:
1.17 matthieu 81: If you have your source tree on an NFS partition, make sure the clock
82: of your server and client are properly synchronised. A test run by
83: configure will fail if the drift is more than one second. And larger
84: drifts will cause other problems during builds anyways.
85:
1.8 matthieu 86: Path
87:
88: To build Xenocara, you need to have /usr/X11R6/bin in your PATH.
89:
1.2 matthieu 90: Sudo
91:
92: If the SUDO variable points to your sudo(8) binary in /etc/mk.conf,
93: 'make build' can be run as a normal user. It will raise its privileges
94: whenever needed with sudo. Otherwise, you need to run make build as
95: root.
96:
1.3 matthieu 97: If you have installed the full Xenocara X sets on your system, you
98: don't need to build all of Xenocara to patch one element. You can go
1.2 matthieu 99: to any module sub-directory and run 'make build' from there.
100:
1.8 matthieu 101: Source directory
102:
103: The variable XSRCDIR can be set either in the environment or in
1.9 matthieu 104: /etc/mk.conf to point to the xenocara source tree, in case you keep it
1.10 matthieu 105: in a non-standard directory (the default is /usr/src/xenocara).
1.8 matthieu 106:
1.2 matthieu 107: Objdirs
108:
109: Xenocara supports objdirs (and it's even the recommended way to build
110: things). Just run 'make obj' at any level before 'make build' to make
1.4 matthieu 111: sure that the object directories are created.
1.13 matthieu 112: XOBJDIR defines the obj directory that is used (defaults to /usr/xobj).
113: It should be created before running 'make obj'.
1.2 matthieu 114:
115: Shadow trees
116:
117: Alternatively, the old 'lndir(1)' method can still be used to build
1.3 matthieu 118: Xenocara outside of its source tree. Just don't use 'make obj' in this
1.2 matthieu 119: case.
120:
121: o Regenerating configure scripts
122: ------------------------------
123:
124: Whenever you touched an import file for GNU autotools (Makefile.am,
125: configure.ac mostly), you need to rebuild the configure script and
1.14 matthieu 126: makefiles skeletons. For that use the following command in the
127: directory where you edited the autotools source files:
1.2 matthieu 128:
129: env XENOCARA_RERUN_AUTOCONF=Yes make -f Makefile.bsd-wrapper build
130:
1.14 matthieu 131: You can also set XENOCARA_RERUN_AUTOCONF in /etc/mk.conf or in the
132: environment to force the regeneration of configure scripts
133: in every component during a make build.
1.2 matthieu 134:
1.15 matthieu 135: o Cleaning in packages managed by autotools
136: -----------------------------------------
137:
138: One common problem when building xenocara is the case where the obj
139: directory didn't exist (or the symbolic link pointed to a non-existent
1.16 matthieu 140: directory) when the source was first built. After fixing this problem,
1.15 matthieu 141: 'configure' will refuse to work in the obj dir, because the source
142: is already configured.
143:
144: To recover from this in one package:
145:
146: rm -f obj
147: make -f Makefile.bsd-wrapper cleandir
148: mkdir XOBJDIR
149: make -f Makefile.bsd-wrapper obj
150: make -f Makefile.bsd-wrapper build
151:
152: or from the root of the xenocara tree:
153:
154: find . -type l -name obj | xargs rm -f
155: make cleandir
156: mkdir XOBJDIR
157: make obj
158: make build
159:
1.16 matthieu 160: for more desperate cases, remove all files from XSRCDIR not in CVS:
1.15 matthieu 161:
162: cd XSRCDIR
163: cvs -q update -PAd -I - | awk '$1=="?" {print $2}' | xargs rm -f
164:
1.19 matthieu 165: o How to build something with debug information?
166: ----------------------------------------------
167:
168: You can use "env CFLAGS=-g make -f Makefile.bsd-wrapper build" to
169: build any module with debugging information, but you'll need to remove
170: XOBJDIR/xorg-config.cache.${MACHINE} before doing that because
171: autoconf caches the value of CFLAGS in its cache.
172:
173: o How to get a core file out of the X server?
174: -------------------------------------------
175:
176: Several things are needed:
177:
178: 1) set kern.nosuidcoredump=2 in /etc/sysctl.conf
179: 2) put
180:
181: Option "NoTrapSignals" "true"
182:
183: in the "ServerFlags" section of /etc/X11/xorg.conf. If such a section
184: doesn't exist, it can be added as follow:
185:
186: Section "ServerFlags"
187: Option "NoTrapSignals" "true"
188: EndSection
189:
190: anywhere in the configuration file.
191:
192: 3) start the X server as root, with the -keepPriv option. A regular
193: user is not allowed to use this option. If you use xdm, you can add
194: the option in /etc/X11/xdm/Xservers. If you want to use startx, you
195: need to run it as root, like this:
196:
197: startx -- /usr/X11R6/bin/X -keepPriv
198:
199: Now the X server will dump core when catching a fatal signal. But it
200: will also not be able to restore the text mode on exit. So be prepared
201: to log in remotely (serial terminal or ssh) to reboot your machine or
202: to restart X.
203:
204: The core dump will be in /var/crash.
205:
206: See also <http://xorg.freedesktop.org/wiki/Development/Documentation/ServerDebugging>
207:
1.15 matthieu 208: --
1.20 ! jolan 209: $OpenBSD: README,v 1.19 2007/06/01 00:19:52 matthieu Exp $
![[BACK]](/icons/back.gif){kind=icon}
Return to README CVS log ![[TXT]](/icons/text.gif){kind=icon}
![[DIR]](/icons/dir.gif){kind=icon}
Up to [local] / xenocara