FreeBSD? [was: compiling, ltmain.sh not found]

[Eric Anholt]

On Wed, 2004-01-14 at 16:38, Nicolas Souchu wrote:
> On Wed, Jan 14, 2004 at 08:52:40AM +0000, Nicolas Souchu wrote:
> > 
> > Hi,
> > 
> > Freshly cvs'ed:
> > 
> > Here is the output of autogen.sh:
> > 
> [...]
> > configure.ac:37: required file `./ltmain.sh' not found
> > Xext/Makefile.am: installing `./depcomp'
> > autoreconf: automake failed with exit status: 1
> 
> Replace AM_PROG_LIBTOOL by AC_PROG_LIBTOOL in configure.ac seems to fixe
> the problem. Libtool 1.5 is also needed to take configure.ac at libtoolize.
> 
> > [...]
> > checking for BSD-compatible nm... /usr/bin/nm -B
> > ./ltconfig: ./ltconfig: No such file or directory
> > configure: error: libtool configure failed
> 
> This was due to a collision between libtool versions.
> 
> It was hard to help me for the second point :)
> 
> BTW, what makes that FreeBSD is not supported?

I've spent a lot of time fighting with autotools both with this project
and glide on FreeBSD.  Usually for fd.o stuff I just roll a distfile
from a linux system and then build on FreeBSD, but for working on new
code it's nice to be able to use ./autogen.sh sorts of things.  What I
ended up with was making a directory full of symlinks, such from
autoconf to autoconf257, so that autoconf 2.57, libtool 1.5, and
automake 1.7 were always found when a versioned name wasn't used.  My
autogen script puts the symlink dir first in the PATH, cats
${LOCALBASE}/share/aclocal/libtool15.m4 and pkg.m4 to acinclude.m4,
because ${LOCALBASE}/share/aclocal17 lacks them, then does the normal
aclocal ; autoheader ; automake --add-missing ; autoconf ; ./configure.

If there's an easier way of doing this that doesn't screw up other
platforms (Doesn't the AC_PROG_LIBTOOL change cause some problems?), I'd
love to see it.

We need a vesa driver for FreeBSD (using the kernel's VESA support, I
expect, as I was utterly defeated in my attempts to use vm86 for it). 
We also need a keyboard driver.  The linux mouse driver should work
fine, I expect.  At that point we should have the current accelerated
drivers working.

While on our family vacation the last few days, I got working on
whacking hw/kdrive/vesa into using the kernel's VESA support for mode
setting.  I think it's pretty close, at least for the modes people
actually want to be using.  If KGI could be integrated for FreeBSD and
provide us with a better solution, that would be excellent. 

-- 
Eric Anholt                                eta@lclark.edu          
http://people.freebsd.org/~anholt/         anholt@FreeBSD.org