Syntax error near unexpected token `UTS_RELEASE,'

[Scott Tam]

Sorry if this a trivial question, but i'm completly new to linux and cipe

I get an error message:

checking for kernel version... ./configure: line 2540: syntax error
near unexpected token `UTS_RELEASE,'
./configure: line 2540: `AX_MACRO_STR(UTS_RELEASE, linux/version.h)'

could someone please help me please?
thanx

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Dick St.Peters]

Scott Tam writes:
> Sorry if this a trivial question, but i'm completly new to linux and cipe
>
> I get an error message:
>
> checking for kernel version... ./configure: line 2540: syntax error
> near unexpected token `UTS_RELEASE,'
> ./configure: line 2540: `AX_MACRO_STR(UTS_RELEASE, linux/version.h)'
>
> could someone please help me please?

Hi,

It looks like you are trying to build cipe without having a kernel
build directory.  It also looks like you're not using the latest cipe
release.

To build cipe you need to have a kernel source directory that has been
used to build a kernel.  The process of building a kernel creates a
file include/linux/version.h, and in that file UTS_RELEASE is defined
as a string with the full kernel version (as returned by "uname -r").

If you didn't have a kernel source directory you'd get a diffferent
error, so presumably you have one.  You'd also have gotten a differnt
error with a clean, unused source directory with no version.h file.
It looks like you have a source directory with a version.h file that
has no UTS_RELEASE definition in it.  This should not happen without
someone manually creating an incomplete version.h file.

I think the reference to line 2540 implies you're using a pre-release
version of cipe 1.6.  Version 1.6.0 has been out for some time, and
for it the UTS_RELEASE check is usually done at about line 2100.

If you're "completly new to linux", trying to build cipe is a tough
place to start.

--
Dick St.Peters, stpeters@...

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Scott Tam]

Hi,

I thought 1.6 was the latest release because i couldn't see any later releases.

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)

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))

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

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

On 11/8/05, Dick St.Peters <stpeters@...> wrote:

> Hi,
>
> It looks like you are trying to build cipe without having a kernel
> build directory.  It also looks like you're not using the latest cipe
> release.
>
> To build cipe you need to have a kernel source directory that has been
> used to build a kernel.  The process of building a kernel creates a
> file include/linux/version.h, and in that file UTS_RELEASE is defined
> as a string with the full kernel version (as returned by "uname -r").
>
> If you didn't have a kernel source directory you'd get a diffferent
> error, so presumably you have one.  You'd also have gotten a differnt
> error with a clean, unused source directory with no version.h file.
> It looks like you have a source directory with a version.h file that
> has no UTS_RELEASE definition in it.  This should not happen without
> someone manually creating an incomplete version.h file.
>
> I think the reference to line 2540 implies you're using a pre-release
> version of cipe 1.6.  Version 1.6.0 has been out for some time, and
> for it the UTS_RELEASE check is usually done at about line 2100.
>
> If you're "completly new to linux", trying to build cipe is a tough
> place to start.
>
> --
> Dick St.Peters, stpeters@...
>

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Dick St.Peters]

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, stpeters@...

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Claus Grill]

Hi,

> *
> 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.

Is OpenVPN as stable as CIPE? I was thinking about trying OpenVPN.

But CIPE works perfect, eventhough OpenVPN is probably less hard to get
running I suppose (No need for kernel modules). But the configuration of CIPE
is set up really fast.

Can OpenVPN deal with reboots and start the tunnel again? But it for sure does
that I suppose.

Regards,

Claus Grill

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Dick St.Peters]

Claus Grill writes:
> Is OpenVPN as stable as CIPE? I was thinking about trying OpenVPN.
>
> But CIPE works perfect, eventhough OpenVPN is probably less hard to get
> running I suppose (No need for kernel modules). But the configuration of CIPE
> is set up really fast.
>
> Can OpenVPN deal with reboots and start the tunnel again? But it for sure does
> that I suppose.

Let me summarize it this way: I sell network tunnels of multiple
types, and OpenVPN is what I use for my own home tunnel.

    - Like CIPE, OpenVPN uses UDP for transport, avoiding the TCP/TCP
      issues.  However, to avoid UDP-application/UDP issues OpenVPN
      can optionally use TCP for transport.

    - OpenVPN is easy to build, easy to configure, and easy to
      maintain.  It uses the 'tun' module included with every Linux
      distribution I know of.  Kernel upgrades do not require any
      OpenVPN changes or rebuilding.

    - OpenVPN glides gracefully through network breakages, remote-peer
      reboots, and dynamic IP changes.

    - OpenVPN supports Linux, *BSD, MacOS, Solaris, and Windows.

    - OpenVPN uses SSL/TLS certificates for authentication, with
      negotiated encryption keys.  (For simple setups, it also
      supports fixed-key operation.  It can even be run without
      authentication or encryption.)

    - OpenVPN supports optional LZO compression.  Net uncompressed
      data transfer rates sometimes exceed wirespeed.

    - OpenVPN supports bridging tunnels.  The tunnel type is a
      run-time option, not a compile-time option.

    - OpenVPN is under active development and maintenance, with a
      substantial user community and active forums.

--
Dick St.Peters, stpeters@...

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>

[Karl Kleinpaste]

"Dick St.Peters" <stpeters@...> writes:
>     - OpenVPN is easy to build, easy to configure, and easy to
>       maintain.  It uses the 'tun' module included with every Linux
>       distribution I know of.  Kernel upgrades do not require any
>       OpenVPN changes or rebuilding.

If you run Fedora Core, you don't even have to build it.  Just pick up
{lzo,openvpn}*.rpm from
http://download.fedora.redhat.com/pub/fedora/linux/extras/4/i386/

I haven't put it to use yet myself -- I need to find the right
combination of time and motivation -- but it's right there.

--
Message sent by the cipe-l@... mailing list.
Unsubscribe: mail majordomo@..., "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>