Non-standard X11 Paths

Dan Nicholson dbn.lists at
Tue Jun 12 10:46:04 PDT 2007

Currently there are a couple issues with packages finding X11
components when they are installed to non-standard locations. I'm not
sure about the exact definition of non-standard, but it seems that
widely accepted prefixes are /usr/X11R5, /usr/X11R6 and /usr/X11. /usr
obviously works, too, since it's the standard toolchain search path.
Here are the two problem areas I know about.

1. Autotooled packages

Typically how an autoconfed package finds the X11 headers and
libraries is by using the autoconf macro AC_PATH_XTRA. You can find
the paths that this macro uses in
/usr/share/autoconf/autoconf/libs.m4. Search for _AC_PATH_X_DIRECT. It
lists a bunch of include directories there. It then does 'sed
s/include/lib/g' to find the libraries. You'll see there's no
/usr/X11R7 or anything in /opt.

You can override this search by passing --x-includes and --x-libraries.

2. Python for the tkinter module

Here's what the search looks like in

        # Check for various platform-specific directories
        if platform == 'sunos5':
        elif os.path.exists('/usr/X11R6/include'):
        elif os.path.exists('/usr/X11R5/include'):
            # Assume default location for X11

So, you won't get to build the tkinter module unless your prefix is
/usr/X11R5, /usr/X11R6, /usr/X11 or /usr. There is no way to override
this location.

Randy had the idea that we should just make a symlink at /usr/X11R6 to
protect against these situations. I'd like to propose for Xorg that we
do `ln -svnf $XORG_PREFIX /usr/X11' if your prefix isn't one of the
"standard locations" I listed above. I'm not a fan of these kind of
compatibility hacks, but I think it's gonna be necessary until
pkg-config is used for X (a long ways off, if ever). There is
convenient location for this here:

For XFree86, I don't know what to do. We sort of say that you install
to /usr/X11R6 or /usr and later make some symlinks like /usr/bin/X11
-> /usr/X11R6/bin. I don't know the history behind those decisions.



More information about the blfs-dev mailing list