manually build x and beyond
Manually Building X and Beyond
The following are notes on manually building latest git-hosted X.org on development DragonFly BSD.
We try something ill-advised, we build a separate version of X.org in another directory, say /opt/xbeta, on the same machine where we have installed the latext pkgsrc. We build a newer, separate, X.org so that we can test newer graphics hardware such as a Radeon HD4550 (r600), but we keep the older pkgsrc X.org because we like to use our faster test machine both for development and as our day-to-day workstation.
The risk is that it is very easy to link into the new test libraries the wrong libraries from pkgsrc.
Disclaimer
The following notes describe alterations to one's system that may leave the graphical user interface based on X.org unusable. Use at one's own risk, and we certainly provide no warranty and make no guarantee of fitness. Because the risk of damaging one's system is so great and because there are other sites such as http://www.x.org/wiki/ModularDevelopersGuide that do provide build scripts, we do not provide ready-to-run scripts.
Despite the above warnings, the purpose of building a separate X.org in a separate directory is to hopefully limit possible damage.
Notes on pkgsrc and interactions with DragonFly BSD
GNU m4 1.4.14 and bison 2.4.2
Some packages have a bug where POSIX spawn definitions are incorrectly redefined for DragonFly BSD, so that forking subprocesses is broken.
Patch both devel/m4 and devel/bison using the patch idea from: http://www.netbsd.org/cgi-bin/query-pr-single.pl?number=43098
Unfortunately the problems are in the work directories so that one needs the knowledge from http://www.netbsd.org/docs/pkgsrc/components.html to even get the patches to be applied.
Install pkgtools/pkgdiff for easier development of patches to pkgsrc work directories.
gstreamer 0.10 and a 128-bit division bug on gcc 4.1.2 for x86_64
The combination of gcc 4.1.2 on DragonFlyBSD for x86_64 (amd64) appears to have a bug where 128-bit integer division is mistakenly optimized to internal functions that do not exist, causing link errors. The current workaround is to either specify the alternate base gcc 4.4 compiler using CCVER=gcc44 or to manually patch the offending source code to ignore autoconf checks for types such as uint128_t or _uint128t.
As of 2010-05-09, we find it necessary on x86_64 to use the following patch for pkgsrc gstreamer0.10, an eventual dependency of the full xfce desktop:
--- pkgsrc/multimedia/gstreamer0.10/Makefile.orig 2010-03-29 16:04:23 -0700
+++ pkgsrc/multimedia/gstreamer0.10/Makefile 2010-03-29 16:09:04 -0700
@@ -44,6 +44,11 @@
.include "../../mk/bsd.prefs.mk"
+# __udivti3 error otherwise
+.if ${OPSYS} == "DragonFly" && ${MACHINE_ARCH} == "x86_64"
+MAKEFLAGS+= CCVER=gcc44
+.endif
+
.if ${OPSYS} == "NetBSD"
# We must have a glib2 compiled with the RTLD_GLOBAL fix; if not, plugins
# won't work at all.
See for example the following bug report for more details: http://mail-index.netbsd.org/pkgsrc-bugs/2010/03/30/msg037304.html
Manually building new X.org
expat and gettext
We start with installing into /opt/xbeta expat 2.0.1 and gettext 0.17.
Git repository for most of X.org
We use the following listing:
freedesktop.org git repository browser
One can easily script getting, updating, and building the projects listed on that page.
Example of using ldd
$ ldd ./libXau.so.6
./libXau.so.6:
libc.so.7 => /usr/lib/libc.so.7 (0x800640000)
$ ldd ./libXdmcp.so.6
./libXdmcp.so.6:
libc.so.7 => /usr/lib/libc.so.7 (0x800640000)
libxcb problem with Python 2.6 cElementTree
Library xcb/libxcb unfortunately needs to be built early and there is a catch for using pkgsrc Python 2.6. Unfortunately at the current time not all of cElementTree appears to be functional; therefore, one needs a patch similar to
diff --git a/src/c_client.py b/src/c_client.py
index d86d05e..36a7039 100755
--- a/src/c_client.py
+++ b/src/c_client.py
@@ -1,5 +1,5 @@
#!/usr/bin/env python
-from xml.etree.cElementTree import *
+from xml.etree.ElementTree import *
from os.path import basename
import getopt
import sys
As of May 20, 2010, the situation for libxcb seems to be more complicated. The latest xcb/proto needs to be installed. If one does not wish to install on top of one's current Python modules, define
export PYTHONPATH=${PREFIX}/lib/python2.6/site-packages
and apply a patch similar to below to change from using Python 2.6's cElementTree to ElementTree
diff --git a/xcbgen/matcher.py b/xcbgen/matcher.py
index e7958fa..16e8273 100644
--- a/xcbgen/matcher.py
+++ b/xcbgen/matcher.py
@@ -7,7 +7,7 @@ we do not create a new type object, we just record the existing one under a new
'''
from os.path import join
-from xml.etree.cElementTree import parse
+from xml.etree.ElementTree import parse
import state
from xtypes import *
diff --git a/xcbgen/state.py b/xcbgen/state.py
index 51efc94..e72dc3e 100644
--- a/xcbgen/state.py
+++ b/xcbgen/state.py
@@ -2,7 +2,7 @@
This module contains the namespace class and the singleton module class.
'''
from os.path import dirname, basename
-from xml.etree.cElementTree import parse
+from xml.etree.ElementTree import parse
import matcher
from error import *
libXext
CCLD libXext.la
/usr/libexec/binutils217/elf/ld: .libs/extutil.o: relocation R_X86_64_PC32 against `xgeExtRegister' can not be used when making a shared object; recompile with -fPIC
/usr/libexec/binutils217/elf/ld: final link failed: Bad value
Use the following patch from http://lists.x.org/archives/xorg-devel/2009-November/003724.html
diff --git a/src/Xge.c b/src/Xge.c
index 7a583e5..2ea5d27 100644
--- a/src/Xge.c
+++ b/src/Xge.c
@@ -294,7 +294,7 @@ _xgeEventToWire(Display* dpy, XEvent* re, xEvent* event)
/*
* Extensions need to register callbacks for their events.
*/
-Bool
+_X_HIDDEN Bool
xgeExtRegister(Display* dpy, int offset, XExtensionHooks* callbacks)
{
XGEExtNode* newExt;
FreeType 2
We install FreeType 2.3.12. It appears that GNUMAKE=gmake is required. Most of the X.org projects use autogen.sh, but here we use a standard call to configure somewhat similar to:
export ACLOCAL="aclocal -I ${PREFIX}/share/aclocal"
export PKG_CONFIG_PATH="${PREFIX}/lib/pkgconfig"
GNUMAKE=gmake ./configure --prefix=${PREFIX} CPPFLAGS="-I${PREFIX}/include -I${PREFIX}/X11/include" LDFLAGS="-L${PREFIX}/lib -Wl,-rpath -Wl,${PREFIX}/lib -L${PREFIX}/X11/lib -Wl,-rpath -Wl,${PREFIX}/lib/X11"
where $PREFIX is where we install X.org, say /opt/xbeta, the first two exports of ACLOCAL and PKG_CONFIG_PATH occur for most X.org projects, CPPFLAGS and LDFLAGS ensure that the $PREFIX include directories and library paths are used, and -Wl,-rpath ... is an incantation that ensures that previous built libtool libraries can be used.
libXfont
autogen.sh script seems to build easier with --without-xmlto option.
Mesa
As of 2010-05-09, known problem with GNU m4 pkgsrc on DragonFly
/usr/pkg/bin/gm4: m4_esyscmd subprocess failed: Operation not permitted
/usr/pkg/bin/gm4:configure.ac:8: cannot run command `${MAKE-make} -s -f bin/version.mk version | tr -d '\n'': Operation not permitted
configure.ac:8: error: Failed to get the Mesa version from `make -f bin/version.mk version`
At one time we patched mesa configure to substitute in the version; however, we now believe it is better to patch pkgsrc GNU m4 as described above.
C99 fpclassify()
At one time a patch similar to below was required, but now it appears to have been patched in the upstream source. fpclassify() is a function introduced in C99. Detecting reliably which features of C99 are supported is always an adventure because few OSes if any implement all of this standard.
diff --git a/src/mesa/main/querymatrix.c b/src/mesa/main/querymatrix.c
index ca292aa..a0969f6 100644
--- a/src/mesa/main/querymatrix.c
+++ b/src/mesa/main/querymatrix.c
@@ -71,7 +71,7 @@ fpclassify(double x)
}
#elif defined(__APPLE__) || defined(__CYGWIN__) || defined(__FreeBSD__) || \
- (defined(__sun) && defined(__C99FEATURES__))
+ defined(__DragonFly__) || (defined(__sun) && defined(__C99FEATURES__))
/* fpclassify is available. */
xserver
If one uses the patches alluded to in the pkgsrc section, one can avoid the following build error:
YACC parser.c
bison: m4 subprocess failed: Operation not permitted
gmake[3]: *** [parser.c] Error 1
Developer documentation appears to now be enabled by default; therefore, if one is bootstrapping a new tree, one might want to use the option to autogen.sh to not build developer documentation:
I experienced the following build error:
GEN Xserver-spec.txt
No way to convert HTML to text found.
Corrected using the autogen.sh flag:
--disable-devel-docs
xinit
diff --git a/xinit.c b/xinit.c
index 313806e..0d31637 100644
--- a/xinit.c
+++ b/xinit.c
@@ -48,6 +48,12 @@ in this Software without prior written authorization from The Open Group.
#endif
#endif
+/* For PRIO_PROCESS and setpriority() */
+#ifdef __DragonFly__
+#include <sys/time.h>
+#include <sys/resource.h>
+#endif /* __DragonFly__ */
+
#include <stdlib.h>
#ifndef SHELL
Building a Separate Version of GNOME
glib
See the bug report at https://bugzilla.gnome.org/show_bug.cgi?id=618754 for an error similar to
/usr/libexec/binutils217/elf/ld: .libs/gthread.o: relocation R_X86_64_PC32
against `_g_mem_thread_init_noprivate_nomessage' can not be used when making a
shared object; recompile with -fPIC
/usr/libexec/binutils217/elf/ld: final link failed: Bad value
This bug is especially a problem because it may be related to some interaction with gcc 4.1.2 only on DragonFly.
The following patch is a complete hack:
diff --git a/configure.in b/configure.in
index 38288c3..51a1c07 100644
--- a/configure.in
+++ b/configure.in
@@ -3033,7 +3033,7 @@ _______EOF
#define G_GNUC_INTERNAL __attribute__((visibility("hidden")))
#elif defined(__SUNPRO_C) && (__SUNPRO_C >= 0x550)
#define G_GNUC_INTERNAL __hidden
-#elif defined (__GNUC__) && defined (G_HAVE_GNUC_VISIBILITY)
+#elif defined (__GNUC__) && defined (G_HAVE_GNUC_VISIBILITY) && !defined(__DragonFly__)
#define G_GNUC_INTERNAL __attribute__((visibility("hidden")))
#else
#define G_GNUC_INTERNAL
Graphics Image Formats
libpng http://www.libpng.org/pub/png/libpng.html version 1.4.2 can be installed using autogen.sh and then configure, in contrast to the X.org projects that pass parameters from autogen.sh to run configure automatically.
Independent JPEG Group's library http://www.ijg.org/ version 8b can be installed using configure alone (there is no autogen.sh).
LibTIFF http://www.remotesensing.org/libtiff/ has a recommended dependency on jpeg. LibTIFF version 3.9.2 can be installed using autogen.sh and then configure.
Running gmake check after building any of the above three projects appears to produce passes tests.
XML
libxml2
autogen.sh calls configure
11 tests fail after gmake check
Cairo
Seems to require
export LDFLAGS="-L${PREFIX}/lib -Wl,-rpath -Wl,${PREFIX}/lib -L${PREFIX}/lib/X11 -Wl,-rpath -Wl,${PREFIX}/lib/X11"
export CPPFLAGS="-I${PREFIX}/include -I${PREFIX}/X11/include"
When using gcc 4.1.2, gmake check gives:
LINK check-link
./.libs/libcairo.so: undefined reference to `__umodti3'
./.libs/libcairo.so: undefined reference to `__udivti3'
When using CCVER=gcc44 to force gcc 4.4, one obtains the worse:
CHECK cairo.h
cc1: error: unrecognized command line option "-Wlogical-op"
CHECK cairo-deprecated.h
cc1: error: unrecognized command line option "-Wlogical-op"
...
The problem is 128-bit division using gcc 4.1.2 as discussed earlier. One can examine src/cairo-wideint.c and see the telltale code enclosed in an if test for HAVE_UINT128_T with 128-bit division if defined.
Pango
Install gnome-common first, required.
If Cairo is not built with CCVER=gcc44, obtain build error similar to
CCLD pango-view
/opt/xcatch/lib/libcairo.so: undefined reference to `__umodti3'
/opt/xcatch/lib/libcairo.so: undefined reference to `__udivti3'
gmake[3]: *** [pango-view] Error 1
Following patch corrects an API change not propagated to the test for gmake check https://bugzilla.gnome.org/show_bug.cgi?id=619456
Not including patch itself because there are tabs. But edit file pango/pangoft2.def and change pango_fc_font_create_metrics_for_context to pango_fc_font_create_base_metrics_for_context
GObject Introspection
cElementTree is changed to ElementTree in files giscanner/girparser.py, giscanner/glibtransformer.py, and giscanner/scannermain.py.
Using pkg_alternatives for a python wrapper fails as a script is generated with
#! /usr/pkg/bin/python
import os
import sys
A shell script cannot use another shell script as its interpreter. What works for now is to manually create /usr/pkg/bin/python as a symlink to /usr/pkg/bin/python2.6.
gtk+
gobject-introspection is listed as a dependency but can be avoided. Use option --disable-introspection to avoid an error
checking for gobject-introspection... yes
./configure: ${INTROSPECTION_GIRDIR/...}: Bad substitution