Re: Syntax error near unexpected token `UTS_RELEASE,'

Scott Tam writes:
> I thought 1.6 was the latest release because i couldn't see any later releases.

1.6.0 is the latest release.  The configure you're using appears to be
from the 1.6.0pre1 pre-release version

> I've specified the source directory but i added '-2.4'. i hope i've
> changed it on the right line! I haven't specified the build directory
> because i wasn't sure where it is. (plz don't laugh)

The conventional place for a kernel build directory is
/usr/src/linux.  However, the stock kernel installation procedure
creates a symlink /lib/modules/`uname -r`/build pointing to the actual
build directory from which the kernel is installed.

> I did "cat /usr/include/linux/version.h"
> and here is the result:
> 
> #define UTS_RELEASE "2.4.20"
> #define LINUX_VERSION_CODE 132116
> #define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))

/usr/include/linux/version.h is the userland version.h.  The one you
want would normally be /usr/src/linux/include/linux/version.h.

It used to be that the kernel's header files were made available to
userspace programs by copying /usr/src/linux/include/linux to
/usr/include/linux (or by symlinking).  For reasons too complex to go
into here, the kernel's include files are no longer suitable for use
by user space programs and are considered private to the kernel.

However, to accomodate the large amount of userspace code that
expects to find various kernel header files in /usr/include/linux,
some of the kernel header files must exist there in a form suitable
for use by userspace code.  A lot of that code is in GLIBC, so these
are often called the "GLIBC kernel headers".

In the GLIBC kernel headers, the UTS_RELEASE entry is just a
placeholder.  Userspace code isn't supposed to depend on what the
kernel release is, so there's no need to keep the GLIBC kernel
header's UTS_RELEASE in sync with the kernel's UTS_RELEASE.  Your
version.h is the one that came with Fedora Core 1, for which the
UTS_RELEASE in the kernel's version.h was "2.4.22-1.2115.nptl".

CIPE builds a kernel module - a piece of the kernel, and it needs the
real kernel headers.

> The whole time I should be only configuring 'configure.in' file right?

'configure.in' is what autoconf uses to build 'configure'.  Your cipe
source should have come with a pre-built 'configure', and you should
not have to run autoconf yourself.

> Yes i know its tough, but i have no choice.  I have to work with Linux.

It's not linux that's tough.  You wouldn't have a Windows novice begin
with building a Windows driver.

Unless you absolutely must use cipe, I would suggest trying OpenVPN,
which has equivalent performance and is a lot easier to build.  It
does not require building a kernel module.  Linux has matured a lot
since cipe was designed, and the hoops cipe had to jump through are no
longer necessary.

--
Dick St.Peters, [email protected] 

--
Message sent by the [email protected] mailing list.
Unsubscribe: mail [email protected], "unsubscribe cipe-l" in body
Other commands available with "help" in body to the same address.
CIPE info and list archive: <URL:http://sites.inka.de/~bigred/devel/cipe.html>