remote debuggings using a gdbserver

god i hope this works.
this would mean i could really honestly start
stepping into the game code (a first)
1. i build a static and installed version gdb-6.3 to the game cd.
2. i build and installed gdb-.63 to my devel box.

but before i do that i want to see if this works so
i took one of my linux boxes and compiled and installed
gdb-6.3 on this box. the i plan to see if i can remotely
run gdb, if this works then i will get everything running
on the cd (the plan is).

well this didnt on the first cut

building a autoconf based project

The following excerpt came from the following html page:
http://inti.sourceforge.net/tutorial/libinti/autotoolsproject.html

Building a GNU Autotools Project

1. The Essential Files
2. The Directory Structure
3. Makefile.am
4. configure.in
5. Generating the Output Files
6. Building and Installing the Project
7. Maintaining the Input Files
8. Some Helpful Links

If you're unfamiliar with the GNU Autotools and want to know how to build and maintain an Autotools project you should read this section. It will take you step-by-step through the process of creating and building a small project, and at the end provide you with some helpful links to more documentation and examples. You should also work through the next section on Internationalization and Localization. It will show you how to add international support to the project.

Autoconf and Automake provide an effective build system to maintain your software, usually on someone else's system. Automake examines source files, determines how they depend on each other, and generates a Makefile so the files can be compiled in the correct order. Autoconf permits automatic configuration of software installation, handling a large number of system quirks to increase portability. Libtool (not discussed here) is a command-line interface to the compiler and linker that makes it easy to generate static and shared libraries.

The Essential Files
The smallest project requires you provide only two files:

* Makefile.am - an input file to automake that specifies a projects build requirements: what needs to be built, and where it goes when installed.
* configure.in - an input file to autoconf that provides the macro invocations and shell code fragments autoconf uses to build a configure script.

The GNU Autotools will generate the rest of the files needed to build the project.

The Directory Structure
Before writing any code for a new project you need to decide on the directory structure the project will use.

* The top-level directory is used for configuration files, such as configure.in, and other sundry files like ChangeLog, COPY (a copy of the project license) and README.
* Any unique library should have its own subdirectory containing all headers and sources, a Makefile.am, and any other library specific files.
* The headers and sources for the main application should be in another subdirectory, typically called src.
* Other directories can include: config for intermediate files, doc for the project documentation and test for the project self-test suite.

The following steps will take you through creating and building the HelloWorld project. The top-level directory for HelloWorld is . You will find the project's headers and sources in the src subdirectory. There are three files: helloworld.cc, helloworld.h and main.cc.

Makfile.am
You must provide a Makefile.am file for each directory in your source tree. Makefile.am for the top-level directory is simple. Create a new text file called Makefile.am in the directory. Add the following line to the file and save it:

SUBDIRS = src

The SUBDIRS variable is used to list the subdirectories that must be built.

Next, in the subdirectory create another text file called Makefile.am. Add the following lines to the file and save it:

bin_PROGRAMS = helloworld

AM_CXXFLAGS = $(INTI_CFLAGS)

helloworld_SOURCES = main.cc helloworld.cc helloworld.h
helloworld_LDADD = $(INTI_LIBS)

The bin_PROGRAMS variable specifies that we want a program called helloworld to be built and installed in the bin directory when make install is run.

The AM_CXXFLAGS macro sets the compiler flags. You should not use CXXFLAGS in Makefile.am because it's unsafe. CXXFLAGS is a user variable that users expect to be able to override.

The helloworld_SOURCES variable specifies the source files used to build the helloworld target. Note that the SOURCES variable for a target is prefixed by the name of the target, in this case helloworld.

The last variable, helloworld_LDADD, specifies the libraries that must be passed to the linker to build the target. This variable is only used by programs and libraries. Note that LDADD uses the same naming rule as the SOURCES variable.

configure.in
The configure.in file must in the project's top-level directory. Change to the directory and create a text file called configure.in. Add the following lines to the file and save it:

AC_INIT(src/main.cc)

PACKAGE=helloworld
VERSION=0.1.0

AM_INIT_AUTOMAKE($PACKAGE, $VERSION)

INTI_REQUIRED_VERSION=1.0.7
PKG_CHECK_MODULES(INTI, inti-1.0 >= $INTI_REQUIRED_VERSION)
AC_SUBST(INTI_CFLAGS)
AC_SUBST(INTI_LIBS)

AC_PROG_CXX

AC_OUTPUT(Makefile src/Makefile)

The AC_INIT macro performs essential initialization for the generated configure script. It takes as an argument a filename from the source directory, to ensure that the source directory has been specified correctly.

The PACKAGE and VERSION variables declare the name and version of the package respectively.

The AM_INIT_AUTOMAKE macro does all the standard initialization required by Automake and takes two arguments, the package name and version number.

The INTI_REQUIRED_VERSION variable specifies the minimum required Inti version, in this case 1.0.7.

The PKG_CHECK_MODULES macro checks for the specified version of the Inti library and if found places the necessary include flags in $(INTI_CFLAGS) and the libraries to link with $(INTI_LIBS). If the correct version is not found configure will report an error.

The AC_PROG_CXX checks for the C++ compiler and sets the variables CXX, GXX and CXXFLAGS.

The last macro AC_OUTPUT must be called at the end of configure.in to create the Makefiles.

Generating the Output Files
Now we need to generate the required output files from the two input files configure.in and Makefile.am. First we need to collect all the macro invocations in configure.in that Autoconf will need to build the configure script. This is done with the following command:

$ aclocal

This generates the file aclocal.m4 and adds it to the current directory.

Next, run autoconf:

$ autoconf

After running autoconf you will find the configure script in the current directory. It's important to run aclocal first because automake relies on the contents on configure.in and aclocal.m4.

There are a few files that the GNU standard says must be present in the top-level directory, and if not found Automake will report an error. Enter the following command to create these files:

$ touch AUTHORS NEWS README ChangeLog

Now we can run automake to create Makefile.in. The --add-missing argument copies some boilerplate files from your Automake installation into the current directory.

$ automake --add-missing

By now, the contents of the directory should be looking a lot like the top-level directory of a GNU package you may have installed before:

aclocal.m4 autom4te.cache config.h.in configure.in depcomp install-sh Makefile.in mkinstalldirs README
AUTHORS ChangeLog configure COPYING INSTALL Makefile.am missing NEWS src

Building and Installing the Project
At this point you should be able to package up your source tree in a tarball and give it to other users to install on their own systems. A user just has to unpack the tarball and run the following commands:

$ ./configure --prefix=some_directory
$ make
$ make install

If you run the above commands and look in your bin directory you will find helloworld. Have a look at the size of the executable. Wow! Its 588 kbytes. That's because it contains all the debugging and compiler symbols needed to debug the program.

Now run the following command:

$ make install-strip

If you look at the size of helloworld now it's a lot smaller, only 35.7 kbytes. The command make install-strip strips out all the debugging symbols. The resulting executable is much smaller and faster but you won't be able to debug the program. As a rule, you should only strip a program when its stable.

Maintaining the Input Files
Everytime you edit any of the GNU Autotools input files in your package, you must regenerate the output files. If you add a new source file to the helloworld_SOURCES variable in Makefile.am you must regenerate Makefile.in. If you are building your package you will need to rerun configure to regenerate the Makefile's. Many project maintainers put the necessary commands to do this into a script called autogen.sh and run this script whenever the output files need to be regenerated.

Create a text file called autogen.sh in the top-level directory and make sure you change its file mode to make it executable. Add the following commands to the file and save it:

#! /bin/sh

aclocal && automake --add-missing && autoconf

Now you can easily run the following commands to update your project's output files, and rebuild the project:

$./autogen.sh
$ ./configure --prefix=/some_directory
$ make
$ make install

I created a project called donothing-0.0.1
containing the following files:
Makefile.am
configure.in
AUTHORS
INTALL
COPYING
INSTALL
THANKS
src/getopt1.c
src/getopt.h
src/Makefile.in
src/getopt.c
src/main.c
src/Makefile.am
src/options.h

i ran the following instructions the root
source directory:
aclocal
autoconf
touch AUTHORS NEWS README Changlog
automake --add-missing
./configure
make

Tada, a GNU project
then I rebuild donothing debug
by:
make clean
make CFLAGS=-g

loaded gdb donothing and stepped through each
line of the prog (main.c)

building X11 the saga continues

Still working on this.
My fist assumption is a working Xvesa
will be the gold standard.
What do I call working?
Xvesa doesnt use PAM
it doesnt use Freetype
and uses only the libs provied by
uclibc package.

I am confused that all the correct
/dev entries are in the correct
place /dev/psaux.

I want the build to be non-exotic.

currently i have been playing
around inside of a uclibc toolchain
chroot. i want to use toolchain
i have built.

telnetd remote gdb

I have figured out how to add the busybox telnetd to work
and have created a hacked version of the busybox passwd
util.
the technique software is
i use ifconfig to sat a static ip address
then add a user and change the users password
via the busybox utils. then this is done
i launch telentd httpd.

the only problem with this hacked up version
of redhat 7.3 is that pam gets in the way
of x11 and telnetd
i removed the file xxx from the /etc/pam.d/telnetd file
and commentd out the xxx line in then /etc/pam.d/login file.
(god i love you timo benc)

building x11

i have come to the conclusion that X11 source code
version 4.2.0 is probably where i will stabilize
out to. why? for one i have been able to compile
it. the newer xorg stuff will not compile
it has this funky checkout via cvs scheme
it blows. lots of the guys of the this project
say move to this move to this [xorg] well
i'll moved to it when it compiles.

what are my goals:
1. build against uclibc.
2. build only what i need.

for 1. i have seen several place where you tell the
existing build system where the uclibc compiler is.
or you set up symbolic links to the cross compiler.

2. this is goal is hindered because i dont know
how the build system for x11 works.
what i have seen is that there are imake files
and from these a makefile is generated? or possible
things are added to the makefile. i do see
text appended to be bottom of makefiles showing
what depends on what.
i wonder if a branch of the x11 tree could be
removed and the build process would work?
just remove the branches that contain
the man pages and anything related utilites
like xeyes or xedit, or ar such things
controlled in the host.def file?
dont know yet.

i dont have to have the latest and greates
i want to build XVesa
no man pages no screen savers nothing
extraneous.

redhat 9 vmware problems

redhat 9 problems inside a vm:
add to the files
/etc/sysconfig/network-scripts/ifcfg-eth[n]
/etc/sysconfig/networking/devices/ifcfg-eth[n]

the following:

check_link_down () {

return 1;

}

ssh login attemptedmc

i downloaded and built the ssh sources:
make all install.
I need to determine where the daemon start scripts are located.
the daemon is located in /usr/sbin/sshd

god i love chroot.
chroot is probably the best thing ever invented.
i can make mini distros on my computer
build them up and tear them down.

divertimento

i have to build a bugzilla/cvs server for work.

1) i need to install ssh so i can login remotely.

2) install mysql

3) install apache 2

4) install bugzilla.

1) ssh.

i dug out of the closes a working P3 machine
and will do the experiments on this box before
making something reall at work.
here are my notes from the unix cookbook.

Starting and stoping sshd on most rpm based systems
is done at
/etc/init.d/sshd stop
/etc/init.d/sshd start

check out what the rpms for mandrake 10 do
ssh will copy a public key to the client i am
using.

i need to set this up and then login remotely.

ssh -l josburn machinename
will log me in locally
but i need a full domain name to login
locally
ssh hostname
host keys are stored in /etc/ssh

i must generate a host key using
ssh-keygen and this must be done
as root
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key

public keys must world-readable but owner writable
mode 644 private keys must abosulte not be anything
but owner readable/writeable mode 600
look up these utils
ssh-agent
ssh-add

as a security measure you would like to ensure that any stray ssh-agent
processes are killed automatically when you log out:
make this entry in you ~/.bash_logout file:
kill $SSH_AGENT_PID

1) i started installing ssh from source

plans to build xvesa

get debian woody.

get xfree pre-4.2 betas

That was with pre-4.2 betas.

cd xc/programs/Xserver/
rm Xvesa
make Xvesa

then cut'n'paste the last gcc line, and add ``-static'' to it.

building xvesa

i was able to build xvesa on stripped down redhat 9 system using
the instructions i found at:
http://www.rule-project.org/article.php3?id_article=51

and after 45 minute build inside the vm and i was able
to execute the xvesa server inside the same vm
at 640x460 and 8bits resolution.

some problems the server build had red-hat all over it.
i did and ldd and it linked to pam (yuck i fucking
hate pam) and linked to several other shared libraries.
this is no go i want the think to be statically
linked.

i just found this after googling
http://jusa.telco-tech.de/diet.html
interesting.
uses dietlibc.

fbtest.c

ok i am currently running mandrake 9.2 and
it looks like it has frame buffer support.

maybe i can

take a look at page:
http://lists.trolltech.com/qt-interest/2002-12/msg01247.html
this dumps some pixels to the framebuffer
this can be good so instead i shortend
the program and just had it return
the current frame buffer size.

#include
#include
#include
#include
#include

int main()
{
int fbfd = 0;
struct fb_var_screeninfo vinfo;
struct fb_fix_screeninfo finfo;
long int screensize = 0;
char *fbp = 0;
int x = 0, y = 0;
long int location = 0;

// Open the file for reading and writing
fbfd = open("/dev/fb0", O_RDWR);
if (!fbfd) {
printf("Error: cannot open framebuffer device.\n");
exit(1);
}
printf("The framebuffer device was opened successfully.\n");

// Get fixed screen information
if (ioctl(fbfd, FBIOGET_FSCREENINFO, &finfo)) {
printf("Error reading fixed information.\n");
exit(2);
}

// Get variable screen information
if (ioctl(fbfd, FBIOGET_VSCREENINFO, &vinfo)) {
printf("Error reading variable information.\n");
exit(3);
}

printf("%dx%d, %dbpp\n", vinfo.xres, vinfo.yres, vinfo.bits_per_pixel );


munmap(fbp, screensize);
close(fbfd);
return 0;
}

what i get is
800x600
which is funny because the current
screen setting i have 1240 by 1024
interesting.

but lets concentrate on building the frame buffer support.

again i should go back over my notes:
here is one of the starting place of this work:

http://www.geocities.com/potato.geo/bootlinuxcd.html
and he says:

Framebuffer

One of my experimental aims is to have an X windows environment on a boot CD. To achieve the widest possible compatibility, I've chosen to enable the Framebuffer console mode and to use the XF86_FBDev X server (its just the one from Slackware 7.1 at the moment). Note: Even though I am aiming for wide compatibility just so I can run X, Framebuffer mode doesn't work with pre VESA 2.0 video cards which means you may not want to add in Framebuffer if all you really need is a console prompt. To activate Framebuffer console mode you need to make sure some things are compiled into the kernel, typically this includes:

[*] VGA text console
[*] Video mode selection support
[*] Support for frame buffer devices (EXPERIMENTAL)
[*] VESA VGA graphics console
[*] Advanced low level driver options
<*> 8 bpp packed pixels support
<*> 16 bpp packed pixels support
<*> 24 bpp packed pixels support
<*> 32 bpp packed pixels support
<*> VGA characters/attributes support
[*] Select compiled-in fonts
[*] VGA 8x8 font
[*] VGA 8x16 font

The other thing that I didn't realise until later is you have to make sure you set a graphical mode for the console when it boots in order to use the X server in default mode. This means putting a specific vga= setting appended to the kernel at boot time. Specifically, you need to change the /isolinux/isolinux.cfg file on the CD so it looks something like:

label linux
kernel vmlinuz
append initrd=initrd.gz vga=791

The '791' means to start up in 1024x768x16bit colour mode. Hard coding the display resolution is fine if you know for certain that your video card/monitor can handle it, but what I've done is to let the user choose a display option at boot time. My isolinux.cfg looks like this:

timeout 30
prompt 1
display menu.txt
default 1
label 1
kernel vmlinuz
append initrd=initrd.gz

label 2
kernel vmlinuz
append initrd=initrd.gz vga=788

label 3
kernel vmlinuz
append initrd=initrd.gz vga=791

menu.txt is a simple text file that looks like:

1) Text Mode
2) 800x600 x 16bit colour
3) 1024x768 x 16bit colour

The user just enters '1' if they want text mode, 2 for 800x600 and so on.

building kdrive (part duex)

i restarted the next day (today)
and it takes forever to build this
and if you find an error or missing lib.
(remember this was nearly empty debian install)
then i have to start the whole thing over
again. i noticed lots of things where
getting build that may not have been needed.

i started looking around and found
the gentoo ebuild for kdrive.

# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/x11-base/kdrive/kdrive-4.3.0-r5.ebuild,v 1.14 2004/11/26 00:39:54 cyfred Exp $

# If you don't want to build the Xvesa server, do this.
# VESA="no" emerge kdrive

# By default, this will build a server with no support for scalable
# fonts (but support for built-in ``fixed'' and ``cursor'' fonts, and
# normal support for bitmap fonts and font-server provided fonts).

IUSE="ipv6 xinerama fbdev speedo type1 cjk truetype freetype font-server xv
debug"

IUSE_VIDEO_CARDS="savage trident sis530 trio ts300 mach64 i810 igs"

inherit eutils flag-o-matic toolchain-funcs x11 linux-info

filter-flags "-funroll-loops"

ALLOWED_FLAGS="-fstack-protector -march -mcpu -O -O1 -Os -O2 -O3 -pipe -fomit-frame-pointer"

# Recently there has been a lot of stability problem in Gentoo-land. Many
# things can be the cause to this, but I believe that it is due to gcc3
# still having issues with optimizations, or with it not filtering bad
# combinations (protecting the user maybe from themselves) yet.
#
# This can clearly be seen in large builds like glibc, where too aggressive
# CFLAGS cause the tests to fail miserbly.
#
# Quote from Nick Jones , who in my opinion
# knows what he is talking about:
#
# People really shouldn't force code-specific options on... It's a
# bad idea. The -march options aren't just to look pretty. They enable
# options that are sensible (and include sse,mmx,3dnow when apropriate).
#
# The next command strips CFLAGS and CXXFLAGS from nearly all flags. If
# you do not like it, comment it, but do not bugreport if you run into
# problems.
#
# (13 Oct 2002)
strip-flags

# Are we using a snapshot ?
USE_SNAPSHOT="no"
PATCHVER="0.5"
MANDIR=${WORKDIR}/man
PATCH_DIR="${WORKDIR}/patch"
BASE_PV="${PV}"
MY_SV="${BASE_PV//\.}"
S="${WORKDIR}/xc"
SRC_PATH="mirror://xfree/${BASE_PV}/source"
HOMEPAGE="http://www.xfree.org"
SRC_URI="${SRC_PATH}/X${MY_SV}src-1.tgz
${SRC_PATH}/X${MY_SV}src-2.tgz
${SRC_PATH}/X${MY_SV}src-3.tgz
mirror://gentoo/${P}-gentoo-${PATCHVER}.tar.bz2"
LICENSE="X11"
SLOT="0"
KEYWORDS="x86 amd64"
# Need portage for USE_EXPAND
DEPEND=">=sys-libs/ncurses-5.1
>=sys-libs/zlib-1.1.3-r2
>=sys-devel/flex-2.5.4a-r5
>=dev-libs/expat-1.95.3
>=sys-apps/sed-4
dev-lang/perl
media-libs/libpng
>=sys-apps/portage-2.0.49-r13"

DESCRIPTION="Xfree86: famous and free X server. Tiny version (KDrive)"

src_unpack() {
unpack ${A}

ebegin "Setting up config/cf/host.def"

# See linux.cf for MMX, 3DNOW and SSE autodetection. (spyderous)

cd ${S}
touch config/cf/host.def
echo "#define XVendorString \"Gentoo Linux (KDrive ${PV}, revision ${PR})\"
#define KDriveXServer YES
#define TinyXServer YES
#define BuildLBX NO
#define BuildDBE YES
#define KdriveServerExtraDefines -DPIXPRIV
#define BuildRandR YES
#define BuildXInputLib YES
#define BuildXTrueType NO
#define ServerXdmcpDefines -DXDMCP
#define BuildFonts NO" >>config/cf/host.def

# We dont really want to spend twice as long compiling libraries
# if they exist of the system allready, so we check and change
# respectively here.
if [ "`best_version virtual/x11`" ] ; then
echo "#define BuildScreenSaverExt NO" >> config/cf/host.def
echo "#define BuildScreenSaverLibrary NO" >> config/cf/host.def
echo "#define SharedLibXss NO" >> config/cf/host.def
echo "#define BuildXextLib NO" >> config/cf/host.def
echo "#define BuildX11Lib NO" >> config/cf/host.def
echo "#define ProjectRoot /usr/X11R6" >> config/cf/host.def
# If the libs exist locally we do not need to build against
# kdrives personal libraries, dont patch to do this.
mv ${PATCH_DIR}/0020* ${PATCH_DIR}/excluded
else
echo "#define BuildScreenSaverExt YES" >> config/cf/host.def
echo "#define BuildScreenSaverLibrary YES" >> config/cf/host.def
echo "#define SharedLibXss YES" >> config/cf/host.def
echo "#define BuildXextLib YES" >> config/cf/host.def
echo "#define BuildX11Lib YES" >> config/cf/host.def
echo "#define ProjectRoot ${S}/usr/X11R6" >> config/cf/host.def
fi

# As far as I know, you can't use Xwrapper for multiple X servers,
# so we have to suid Xfbdev and Xvesa. mharris (redhat) also does
# this.
echo "#define InstallXserverSetUID YES" >> config/cf/host.def
echo "#define BuildServersOnly YES" >> config/cf/host.def

if [ "`gcc-version`" != "2.95" ] ; then
# Should fix bug #4189. gcc-3.x have problems with -march=pentium4
# and -march=athlon-tbird
replace-flags "-march=pentium4" "-march=pentium3"
replace-flags "-march=athlon-tbird" "-march=athlon"

# Without this, modules breaks with gcc3
if [ "`gcc-version`" = "3.1" ] ; then
append-flags "-fno-merge-constants"
append-flags "-fno-merge-constants"
fi
fi

get_version
if [ "${KV_MAJOR}" -ge "2" -a "${KV_MINOR}" -ge "4" ] || ( [ -e "${ROOT}/usr/src/linux" ] && [ ! $(kernel_is "2" "2") ] ) || [ "$(uname -r | cut -d. -f1,2)" != "2.2" ]
then
echo "#define HasLinuxInput YES" >> config/cf/host.def
fi

echo "#define OptimizedCDebugFlags ${CFLAGS}" >> config/cf/host.def
echo "#define OptimizedCplusplusDebugFlags ${CXXFLAGS}" >> config/cf/host.def

if use debug ; then
echo "#define XFree86Devel YES" >> config/cf/host.def
echo "#define DoLoadableServer NO" >>config/cf/host.def
else
# use less ram .. got this from Spider's makeedit.eclass :)
echo "#define GccWarningOptions -Wno-return-type -w" >> config/cf/host.def
fi

# Xvesa isn't available on non-x86, non-gcc platforms.
# See http://lists.debian.org/debian-x/2000/debian-x-200012/msg00029.html
if vesa no || [ "${ARCH}" != "x86" ] ; then
echo "#define XvesaServer NO" >> config/cf/host.def
else
echo "#define XvesaServer YES" >> config/cf/host.def
fi

use fbdev && echo "#define XfbdevServer YES" >> config/cf/host.def || echo "#define XfbdevServer NO" >> config/cf/host.def

use ipv6 && echo "#define HasIPv6 YES" >> config/cf/host.def

use xinerama && echo "#define BuildXinerama YES" >> config/cf/host.def

local KDRIVE_XF_SERVERS="Savage Trident Sis530 Trio TS300 Igs i810 mach64"
for i in ${KDRIVE_XF_SERVERS} ; do
# I wish it worked like this. (spyderous)
# if use video_cards_${i/[A-Z]/[a-z]} ; then
if use `echo video_cards_${i} | tr [:upper:] [:lower:]` ; then
echo "#define X${i}Server YES" >> config/cf/host.def
fi
done

# Set up font support
use speedo && echo "#define BuildSpeedo YES" >> config/cf/host.def
use type1 && echo "#define BuildType1 YES" >> config/cf/host.def
use cjk && echo "#define BuildCID YES" >> config/cf/host.def
use truetype && echo "#define BuildXTrueType YES" >> config/cf/host.def
use freetype && echo "#define BuildFreeType YES" >> config/cf/host.def
use font-server && echo "#define FontServerAccess YES" >> config/cf/host.def

# Video
use xv && echo "#define BuildXvExt YES" >> config/cf/host.def

eend 0

# Bulk patching from all over
cd ${WORKDIR}
EPATCH_SUFFIX="patch" epatch ${PATCH_DIR}

# We need to modify xmakefile after it has been created
if [ ! "`best_version virtual/x11`" ] ; then
ebegin "Creating fake X includes..."
MY_PROJROOT="${S}/usr/X11R6/include/"
MY_INCROOT="${S}/include"
MY_LIBROOT="${S}/lib"
MY_HERE="./"

mkdir -p ${MY_PROJROOT}
cd ${MY_INCROOT}
for i in `ls ${MY_HERE}` ; do
ln -sf ${MY_INCROOT}/${i} ${MY_PROJROOT}
done

cd ${MY_LIBROOT}
for i in `ls ${MY_HERE}` ; do
ln -sf ${MY_LIBROOT}/${i} ${MY_PROJROOT}
done

cd ${MY_PROJROOT} && rm -f Imakefile Makefile
ln -sf ${MY_PROJROOT}/extensions ${MY_PROJROOT}/X11/extensions
ln -sf ${S}/lib ${S}/usr/X11R6/lib
eend 0
fi

# Fixing bugs #68531 and #65758 -- this will disable toshiba dpms support
sed '/#ifndef TOSHIBA_SMM/,/#endif/d' -i ${S}/programs/Xserver/hw/kdrive/vesa/vesa.c
}

src_compile() {

# Set MAKEOPTS to have proper -j? option ..
get_number_of_jobs

# If a user defines the MAKE_OPTS variable in /etc/make.conf instead of
# MAKEOPTS, they'll redefine an internal X11 Makefile variable and the
# X11 build will silently die. This is tricky to track down, so I'm
# adding a preemptive fix for this issue by making sure that MAKE_OPTS is
# unset. (drobbins, 08 Mar 2003)
unset MAKE_OPTS

einfo "Building KDrive..."
emake World WORLDOPTS="" || die

# This is dirty, we know, but there is no need to build man pages
# for a whole pile of nothing. As such we are just going to copy
# across the three needed man pages.
einfo "Making and installing man pages..."
mkdir -p ${MANDIR}
MY_MAN_BASE="${S}/programs/Xserver/hw/kdrive"

if ! use fbdev ; then
# We need to regenerate some makefiles for fbdev
echo "#define XfbdevServer YES" >> config/cf/host.def
cd ${S}/programs && make Makefiles > /dev/null || die "Xfbdev Makefile regeneration error..."
fi

# We have a complete set of makefiles so lets just build what we need
cd ${MY_MAN_BASE}
emake DESTDIR=${MANDIR} install.man || die "Kdrive man page install..."
emake DESTDIR=${MANDIR} -C vesa install.man || die "Xvesa man page install..."
emake DESTDIR=${MANDIR} -C fbdev install.man || die "Xfbdev man page install..."

}

src_install() {

exeinto /usr/X11R6/bin

# Install Xvesa
if [ -z "`vesa no`" ] ; then
doexe programs/Xserver/Xvesa
fperms 4711 /usr/X11R6/bin/Xvesa
fi

# Install Xfbdev
if use fbdev ; then
doexe programs/Xserver/Xfbdev
fperms 4711 /usr/X11R6/bin/Xfbdev
fi

# Install the other servers
local KDRIVE_SERVERS="savage trident sis530 trio ts300 igs i810 mach64"
for i in ${KDRIVE_SERVERS} ; do
if use video_cards_${i} ; then
doexe programs/Xserver/X${i}
fperms 4711 /usr/X11R6/bin/X${i}
fi
done

# Install our startx script
doexe ${PATCH_DIR}/startxkd

# Install man pages
if [ "`best_version virtual/x11`" ] ; then
doman -x11 ${MANDIR}/usr/X11R6/man/man1/X{kdrive,vesa,fbdev}.1x
else
doman -x11 ${MANDIR}/${S}/usr/X11R6/man/man1/X{kdrive,vesa,fbdev}.1x
fi
}

pkg_postinst() {
einfo "You may edit /usr/X11R6/bin/startxkd to your preferences."
einfo "Xvesa is the default."
einfo "Or you can use something like:"
einfo "\"xinit -- /usr/X11R6/bin/Xvesa :0 -screen 1280x1024x16 -nolisten tcp\"."
einfo "Your ~/.xinitrc will be used if you use xinit."
}

# For allowing Xvesa build to be disabled
vesa() {
has "$1" "${VESA}"
}

i boiled out of that
the following.
#define KDriveXServer YES
#define TinyXServer YES
#define BuildLBX NO
#define BuildDBE YES
#define KdriveServerExtraDefines -DPIXPRIV
#define BuildRandR YES
#define BuildXInputLib YES
#define BuildXTrueType NO
#define ServerXdmcpDefines -DXDMCP
#define BuildFonts NO
#define BuildScreenSaverExt NO
#define BuildScreenSaverLibrary NO
#define SharedLibXss NO
#define BuildXextLib NO
#define BuildX11Lib NO
#define ProjectRoot /usr/X11R6
#define XvesaServer YES
#define XfbdevServer YES
#define XfbdevServer NO

deleted the whole xc directory
untar-ed the XFree86-4.4.0 tar files
copy the above host.def to the
the ./xc/config/cf directory
then moved back up to xc and did
make World

this has again crashed

what do hope to get?
tinx but if could make a timo derivative
that indeed had x11 that would be
ok as well.

more ideas on building kdrive.
http://www.pps.jussieu.fr/~jch/software/kdrive.html
again the same ideas.
get the xfree86 code than create a host.def file
and make World.

my suspiction is that i am not making the kernel
with frame buffer support or that when im
loading the kernel im not telling it to
enable frame buffer support.
i found this comment :
Using the Xfbdev server requires making the framebuffer device available at boot time. I do it by adding vga=788 (for 800x600) to lilo.conf.
in the web page
http://www.rule-project.org/en/sw/kdrive.php
I am not using lilo but i am using isolinux so i need
to add the following to the isolinux.cfg file
vga=788 but when i do this it barfs.
so i am rebuilding the kernel and
trying to get frame buffer support to work.
i found this link

building kdrive/tinyx

i am now the long long path of building tinyx/kdrive.
i gather that this small linux distributions
descend from keith packards build in the ancient
times (92)

It looksl like i have a coupld of choices
available to me:
use the xfree xorg sources as a starting point.
there are instructions on the net for doing this.

i can build
i have been successful in building the tinyx
that i have derived from the uclibc buildroot
but it doesn't work: the complaint is that
it is un able to open the device
/dev/fb0
initially i check to see that the device was
present it was. i then modified
the section of code opens the device.

i am now goofing around with building tinyx
on a virginal debian system. (vmware)

updated the packages:

http://www.debian.org/doc/FAQ/ch-uptodate.en.html

i changed the type from stable to testing.
hopefully this will give me
then did the cvs mambo to download the xsession
sources
i tried running the ./autogen.sh script
and i get the error:

aclocal: configure.ac: 34: macro `AM_PROG_AS' not found in library
aclocal: configure.ac: 40: macro `AM_PROG_LIBTOOL' not found in library
autoreconf: aclocal failed with exit status:1

then checked the build page
http://freedesktop.org/wiki/Software_2fXserver_2fInstallGuide
it states that you need:
automake --version must report 1.7.x
i have version 1.4-p6
ok how do i upgrade this debian system?
simple i did

apt-get install automake1.7
the ran automake --version and the version
was still 1.4x ...
then had to do apt-get remove automake and
then istall the package using
dpkg automake-1.7x

then again i ran ./autogen.sh
and it chokes:

configure error C++ preprocessor "/lib/cpp" fails sanity check
See `config.log' for more details.

then found i was missing the g++ packages
and did apt-get install g++
the problem went way

another problem :

checking for xdmcp ... Package xdmcp was not found in the pk-config search path.
perhaps you should add the directory containing `xdmcp.pc'


also the debian web page is organized around
a stable/testing listing of deb packages

i have
via cvs
see
http://freedesktop.org/Software/Xserver