GNU bug report logs - #13818
24.3.50; Bootstrap failed on Cygwin due to revno: 111870

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 13818 in the body.
You can then email your comments to 13818 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3.50; Bootstrap failed on Cygwin due to revno: 111870
Date: Tue, 26 Feb 2013 16:23:37 +0900

In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
 of 2013-02-26 on localhost
Bzr revision: 111880 monnier <at> iro.umontreal.ca-20130225232750-8wmx78e4uz1u7tfk
Windowing system distributor `The Cygwin/X Project', version 11.0.11302000
Configured using:
 `configure --verbose --with-x-toolkit=lucid --without-imagemagick
 --without-dbus --without-gconf --without-gsettings'

When dumping temacs it stops by the following error:

vm-limit.o: In function `memory_warnings':
src/vm-limit.c:239: undefined reference to `_data_start'

Please demand to me if other info is required.   Thanks.

Message #8 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 13818 <at> debbugs.gnu.org
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Tue, 26 Feb 2013 07:42:45 -0500

On 2/26/2013 2:23 AM, Katsumi Yamaoka wrote:
> In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
>   of 2013-02-26 on localhost
> Bzr revision: 111880 monnier <at> iro.umontreal.ca-20130225232750-8wmx78e4uz1u7tfk
> Windowing system distributor `The Cygwin/X Project', version 11.0.11302000
> Configured using:
>   `configure --verbose --with-x-toolkit=lucid --without-imagemagick
>   --without-dbus --without-gconf --without-gsettings'
>
> When dumping temacs it stops by the following error:
>
> vm-limit.o: In function `memory_warnings':
> src/vm-limit.c:239: undefined reference to `_data_start'

data_start used to be defined in pre-crt0.c on Cygwin, but this file was 
removed.  Paul, can you help?

Ken

Message #11 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 13818 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Tue, 26 Feb 2013 09:35:42 -0800

On 02/26/13 04:42, Ken Brown wrote:
> On 2/26/2013 2:23 AM, Katsumi Yamaoka wrote:
>> In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
>>   of 2013-02-26 on localhost
>> Bzr revision: 111880 monnier <at> iro.umontreal.ca-20130225232750-8wmx78e4uz1u7tfk
>> Windowing system distributor `The Cygwin/X Project', version 11.0.11302000
>> Configured using:
>>   `configure --verbose --with-x-toolkit=lucid --without-imagemagick
>>   --without-dbus --without-gconf --without-gsettings'
>>
>> When dumping temacs it stops by the following error:
>>
>> vm-limit.o: In function `memory_warnings':
>> src/vm-limit.c:239: undefined reference to `_data_start'

Can you please give the full shell command that
generated that line?  I assume it's something like
"gcc ... -o temacs ..." but would like the details.

> data_start used to be defined in pre-crt0.c on Cygwin,
> but this file was removed.

data_start is now supposed to be defined in vm-limit.c,
on hosts where the linker does not define it for you.

Is there some significance to the leading underscore
in that diagnostic?  (Is "_" automatically prepended
to external symbols on Cygwin?)

What does config.log say, after it says
"checking for data_start"?

What is the value of HAVE_DATA_START in src/config.h?

Also, please examine the output of "gcc -E ... vm-limit.c",
where "..." contains the same flags as used for compiling
vm-limit.c, to see how data_start was declared and defined
in the preprocessor output.

Message #14 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Katsumi Yamaoka <yamaoka <at> jpl.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 13818 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#13818: 24.3.50;
	Bootstrap failed on Cygwin due to revno: 111870
Date: Wed, 27 Feb 2013 07:59:24 +0900

Paul Eggert wrote:
> On 02/26/13 04:42, Ken Brown wrote:
>> On 2/26/2013 2:23 AM, Katsumi Yamaoka wrote:
>>> In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
>>>   of 2013-02-26 on localhost
>>> Bzr revision: 111880 monnier <at> iro.umontreal.ca-20130225232750-8wmx78e4uz1u7tfk
>>> Windowing system distributor `The Cygwin/X Project', version 11.0.11302000
>>> Configured using:
>>>   `configure --verbose --with-x-toolkit=lucid --without-imagemagick
>>>   --without-dbus --without-gconf --without-gsettings'
>>>
>>> When dumping temacs it stops by the following error:
>>>
>>> vm-limit.o: In function `memory_warnings':
>>> src/vm-limit.c:239: undefined reference to `_data_start'

> Can you please give the full shell command that
> generated that line?  I assume it's something like
> "gcc ... -o temacs ..." but would like the details.

Here it is:
--8<---------------cut here---------------start------------->8---
gcc -std=gnu99 -Demacs  -I. -I/Work/emacs/src  -I../lib -I/Work/emacs/src/../lib    -I/usr/include/freetype2      -D_REENTRANT -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/libpng15 -I/usr/include/pixman-1 -I/usr/include/freetype2     -I/usr/include/libxml2      -I/usr/include/freetype2       -MMD -MF deps/.d -MP   -I/usr/include/p11-kit-1      -g3 -O2    \
  -o temacs vm-limit.o dispnew.o frame.o scroll.o xdisp.o menu.o xmenu.o window.o  charset.o coding.o category.o ccl.o character.o chartab.o bidi.o  cm.o term.o terminal.o xfaces.o xterm.o xfns.o xselect.o xrdb.o xsmfns.o xsettings.o xgselect.o    emacs.o keyboard.o macros.o keymap.o sysdep.o  buffer.o filelock.o insdel.o marker.o  minibuf.o fileio.o dired.o  cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o  alloc.o data.o doc.o editfns.o callint.o  eval.o floatfns.o fns.o font.o print.o lread.o  syntax.o unexcw.o bytecode.o  process.o gnutls.o callproc.o  region-cache.o sound.o atimer.o  doprnt.o intervals.o textprop.o composite.o xml.o inotify.o  profiler.o     sheap.o cygw32.o xfont.o ftfont.o xftfont.o ftxfont.o   fontset.o fringe.o image.o  terminfo.o  gmalloc.o   lastfile.o widget.o  ../lib/libgnu.a    ../lwlib/liblw.a  -ltiff -ljpeg -lpng -lz -lm -lgif -lXpm  -lXaw3d -lXmu -lXt -lSM -lICE -lXext -lX11 -lXrender -lXft -lXrender -lfontconfig -lexpat -lfreetype -lz -lbz2 -lX11 -lxcb -lXau -lXdmcp     -lrsvg-2 -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 -lgobject-2.0 -lffi -lpixman-1 -lfontconfig -lexpat -lfreetype -lbz2 -lpng15 -lm -lz -lxcb-shm -lxcb-render -lXrender -lXext -lglib-2.0 -lintl -liconv -lpcre -lX11 -lxcb -lXau -lXdmcp            -lxml2 -lz -liconv -lm       -lncurses -lelf     -lfreetype -lz -lbz2   -lfontconfig -lexpat -lfreetype -lz -lbz2       -L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz   -lpthread    \
  
vm-limit.o: In function `memory_warnings':
/Work/emacs/src/vm-limit.c:239: undefined reference to `_data_start'
collect2: ld returned 1 exit status
Makefile:632: recipe for target `temacs.exe' failed
--8<---------------cut here---------------end--------------->8---

>> data_start used to be defined in pre-crt0.c on Cygwin,
>> but this file was removed.

> data_start is now supposed to be defined in vm-limit.c,
> on hosts where the linker does not define it for you.

> Is there some significance to the leading underscore
> in that diagnostic?  (Is "_" automatically prepended
> to external symbols on Cygwin?)

> What does config.log say, after it says
> "checking for data_start"?

`configure options...` says:
checking for data_start... yes

(There's nothing about data_start in config.log .)

> What is the value of HAVE_DATA_START in src/config.h?

#define HAVE_DATA_START 1

> Also, please examine the output of "gcc -E ... vm-limit.c",
> where "..." contains the same flags as used for compiling
> vm-limit.c, to see how data_start was declared and defined
> in the preprocessor output.

Nothing is returned.  What `make' does then is:
gcc -std=gnu99 -c  -Demacs  -I. -I/Work/emacs/src  -I../lib -I/Work/emacs/src/../lib    -I/usr/include/freetype2      -D_REENTRANT -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/libpng15 -I/usr/include/pixman-1 -I/usr/include/freetype2     -I/usr/include/libxml2      -I/usr/include/freetype2       -MMD -MF deps/vm-limit.d -MP   -I/usr/include/p11-kit-1      -g3 -O2 vm-limit.c

Letting `configure' label Cygwin as it doesn't have data_start
might be one solution.

Thanks.

Message #17 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 13818 <at> debbugs.gnu.org
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Tue, 26 Feb 2013 18:13:31 -0500

On 2/26/2013 12:35 PM, Paul Eggert wrote:
> On 02/26/13 04:42, Ken Brown wrote:
>> On 2/26/2013 2:23 AM, Katsumi Yamaoka wrote:
>>> In GNU Emacs 24.3.50.1 (i686-pc-cygwin, X toolkit, Xaw3d scroll bars)
>>>    of 2013-02-26 on localhost
>>> Bzr revision: 111880 monnier <at> iro.umontreal.ca-20130225232750-8wmx78e4uz1u7tfk
>>> Windowing system distributor `The Cygwin/X Project', version 11.0.11302000
>>> Configured using:
>>>    `configure --verbose --with-x-toolkit=lucid --without-imagemagick
>>>    --without-dbus --without-gconf --without-gsettings'
>>>
>>> When dumping temacs it stops by the following error:
>>>
>>> vm-limit.o: In function `memory_warnings':
>>> src/vm-limit.c:239: undefined reference to `_data_start'

I see that Katsumi just answered, but here are the answers on my system.

> Can you please give the full shell command that
> generated that line?  I assume it's something like
> "gcc ... -o temacs ..." but would like the details.

gcc -std=gnu99 -Demacs  -I. -I/home/kbrown/src/emacs/test/src  -I../lib 
-I/home/kbrown/src/emacs/test/src/../lib    -D_REENTRANT 
-I/usr/include/gtk-3.0 -I/usr/include/atk-1.0 
-I/usr/include/at-spi2-atk/2.0 -I/usr/include/pango-1.0 
-I/usr/include/gio-unix-2.0/ -I/usr/include/cairo 
-I/usr/include/gdk-pixbuf-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/harfbuzz 
-I/usr/include/freetype2 -I/usr/include/pixman-1 -I/usr/include/libpng15 
  -DGDK_DISABLE_DEPRECATION_WARNINGS -I/usr/include/freetype2 
-D_REENTRANT -I/usr/include/librsvg-2.0 -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include -I/usr/include/gdk-pixbuf-2.0 
-I/usr/include/cairo -I/usr/include/libpng15 -I/usr/include/pixman-1 
-I/usr/include/freetype2   -fopenmp -I/usr/include/ImageMagick 
-I/usr/include/libxml2   -I/usr/include/dbus-1.0 
-I/usr/lib/dbus-1.0/include    -D_REENTRANT -I/usr/include/glib-2.0 
-I/usr/lib/glib-2.0/include   -D_REENTRANT -I/usr/include/gconf/2 
-I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include 
-I/usr/include/freetype2       -MMD -MF deps/.d -MP 
-I/usr/include/p11-kit-1      -g3 -O2    \
  -o temacs vm-limit.o dispnew.o frame.o scroll.o xdisp.o menu.o 
xmenu.o window.o  charset.o coding.o category.o ccl.o character.o 
chartab.o bidi.o  cm.o term.o terminal.o xfaces.o xterm.o xfns.o 
xselect.o xrdb.o xsmfns.o xsettings.o xgselect.o gtkutil.o 
emacsgtkfixed.o dbusbind.o  emacs.o keyboard.o macros.o keymap.o 
sysdep.o  buffer.o filelock.o insdel.o marker.o  minibuf.o fileio.o 
dired.o  cmds.o casetab.o casefiddle.o indent.o search.o regex.o undo.o 
 alloc.o data.o doc.o editfns.o callint.o  eval.o floatfns.o fns.o 
font.o print.o lread.o  syntax.o unexcw.o bytecode.o  process.o gnutls.o 
callproc.o  region-cache.o sound.o atimer.o  doprnt.o intervals.o 
textprop.o composite.o xml.o inotify.o  profiler.o     sheap.o cygw32.o 
xfont.o ftfont.o xftfont.o ftxfont.o   fontset.o fringe.o image.o 
terminfo.o  gmalloc.o   lastfile.o   ../lib/libgnu.a      -ltiff -ljpeg 
-lpng -lz -lm -lgif -lXpm  -lgtk-3 -latk-bridge-2.0 -lgdk-3 -latk-1.0 
-lXinerama -lXi -lXrandr -lXcursor -lXcomposite -lXdamage 
-lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo-gobject -lgio-2.0 -lXfixes 
-lpangoft2-1.0 -lharfbuzz -lpango-1.0 -lcairo -lpixman-1 -lfontconfig 
-lexpat -lfreetype -lbz2 -lxcb-shm -lxcb-render -lXrender -lXext -lX11 
-lxcb -lXau -lXdmcp -lpng15 -lm -lz -lgmodule-2.0 -lgobject-2.0 -lffi 
-lglib-2.0 -lintl -liconv -lpcre   -lSM -lICE -lX11 -lXrender -lXft 
-lXrender -lfontconfig -lexpat -lfreetype -lz -lbz2 -lX11 -lxcb -lXau 
-lXdmcp     -lrsvg-2 -lgio-2.0 -lgdk_pixbuf-2.0 -lcairo -lgmodule-2.0 
-lgobject-2.0 -lffi -lpixman-1 -lfontconfig -lexpat -lfreetype -lbz2 
-lpng15 -lm -lz -lxcb-shm -lxcb-render -lXrender -lXext -lglib-2.0 
-lintl -liconv -lpcre -lX11 -lxcb -lXau -lXdmcp   -lMagickWand 
-lMagickCore       -ldbus-1 -lpthread -lrt      -lxml2 -lz -liconv -lm 
     -lncurses  -lgio-2.0 -lz -lgmodule-2.0 -lgobject-2.0 -lffi 
-lglib-2.0 -lintl -liconv -lpcre   -lgconf-2 -ldbus-1 -lpthread -lrt 
-lgio-2.0 -lz -lgmodule-2.0 -lgobject-2.0 -lffi -lglib-2.0 -lintl 
-liconv -lpcre   -lgobject-2.0 -lffi -lglib-2.0 -lintl -liconv -lpcre 
  -lfreetype -lz -lbz2   -lfontconfig -lexpat -lfreetype -lz -lbz2 
  -L/usr/bin -lgnutls -lnettle -lhogweed -lgmp -ltasn1 -lp11-kit -lz 
-lpthread

>> data_start used to be defined in pre-crt0.c on Cygwin,
>> but this file was removed.
>
> data_start is now supposed to be defined in vm-limit.c,
> on hosts where the linker does not define it for you.

The problem seems to be that HAVE_DATA_START is defined to 1, but 
DATA_START is not defined.  See below.

> Is there some significance to the leading underscore
> in that diagnostic?  (Is "_" automatically prepended
> to external symbols on Cygwin?)

I think it's automatically prepended.

> What does config.log say, after it says
> "checking for data_start"?

configure:10083: checking for data_start
configure:10099: gcc -std=gnu99 -o conftest.exe -g3 -O2     conftest.c  >&5
configure:10099: $? = 0
configure:10107: result: yes

> What is the value of HAVE_DATA_START in src/config.h?

1

> Also, please examine the output of "gcc -E ... vm-limit.c",
> where "..." contains the same flags as used for compiling
> vm-limit.c, to see how data_start was declared and defined
> in the preprocessor output.

It's declared as

  extern char data_start[];

but never defined.  Apparently DATA_START is not defined.  How is that 
supposed to happen?

Ken

Message #20 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Katsumi Yamaoka <yamaoka <at> jpl.org>
Cc: 13818 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Wed, 27 Feb 2013 00:02:25 -0800

On 02/26/2013 02:59 PM, Katsumi Yamaoka wrote:
> (There's nothing about data_start in config.log .)

Odd.  Ken Brown said there was something in his config.log.
For now I'll assume his version.

On 02/26/2013 03:13 PM, Ken Brown wrote:
> The problem seems to be that HAVE_DATA_START is defined to 1,
> but DATA_START is not defined.

That should be OK.  HAVE_DATA_START says that the
external symbol data_start works.  DATA_START is
a macro, which can mean something else and which is
to some extent independent of HAVE_DATA_START.
(Yes, it's confusing...)


> configure:10083: checking for data_start
> configure:10099: gcc -std=gnu99 -o conftest.exe -g3 -O2     conftest.c  >&5
> configure:10099: $? = 0
> configure:10107: result: yes

If I'm understanding things correctly, this means the
following little test program compiles and links OK.
Can you please check this?

extern char data_start[];
char ch;                                              
int                                                                             
main ()                                                                         
{                                                                               
  return data_start == &ch;                                                       
}

If this compiles and links, we need to find out why
the similar usage in vm-limit.c does not link.

Can you please compile the above program
with gcc -std=gnu99 -O2 -S and see what
the machine code looks like?

Also, suppose we change this test program to the following
instead -- does this test program compile and link?

extern char data_start[];
char ch;                                              
int                                                                             
main ()                                                                         
{                                                                               
  return data_start < &ch;                                                       
}


>> Also, please examine the output of "gcc -E ... vm-limit.c",
>> where "..." contains the same flags as used for compiling
>> vm-limit.c, to see how data_start was declared and defined
>> in the preprocessor output.
> 
> It's declared as
> 
>   extern char data_start[];
> 
> but never defined.

That should be OK, since the test program linked.
That is, the linker should automatically define
data_start; the program shouldn't have to define it.
But for some reason it's working in the test program
but not for vm-limit.c, and we need to figure out why
there's a discrepancy.

Message #23 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 13818 <at> debbugs.gnu.org
Subject: Re: bug#13818: 24.3.50;
	Bootstrap failed on Cygwin due to revno: 111870
Date: Wed, 27 Feb 2013 09:34:00 +0100

Paul Eggert <eggert <at> cs.ucla.edu> writes:

> extern char data_start[];
> char ch;                                              
> int                                                                             
> main ()                                                                         
> {                                                                               
>   return data_start == &ch;                                                       

The compiler can deduce that data_start can never equal &ch.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Message #26 received at 13818 <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 13818 <at> debbugs.gnu.org
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Wed, 27 Feb 2013 06:25:15 -0500

[Message part 1 (text/plain, inline)]

On 2/27/2013 3:02 AM, Paul Eggert wrote:
> If I'm understanding things correctly, this means the
> following little test program compiles and links OK.
> Can you please check this?
>
> extern char data_start[];
> char ch;
> int
> main ()
> {
>    return data_start == &ch;
> }

It compiles and links OK.  But maybe Andreas explained why.

> If this compiles and links, we need to find out why
> the similar usage in vm-limit.c does not link.
>
> Can you please compile the above program
> with gcc -std=gnu99 -O2 -S and see what
> the machine code looks like?

Attached.

> Also, suppose we change this test program to the following
> instead -- does this test program compile and link?
>
> extern char data_start[];
> char ch;
> int
> main ()
> {
>    return data_start < &ch;
> }

No, this gives the "undefined reference to `_data_start'" error.  Making 
that change in configure.ac fixes the problem.

Ken

[test.s (text/plain, attachment)]

Message #31 received at 13818-done <at> debbugs.gnu.org (full text, mbox):

From: Ken Brown <kbrown <at> cornell.edu>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Katsumi Yamaoka <yamaoka <at> jpl.org>, 13818-done <at> debbugs.gnu.org
Subject: Re: bug#13818: 24.3.50; Bootstrap failed on Cygwin due to revno:
	111870
Date: Wed, 27 Feb 2013 22:25:18 -0500

On 2/27/2013 6:25 AM, Ken Brown wrote:
>> Also, suppose we change this test program to the following
>> instead -- does this test program compile and link?
>>
>> extern char data_start[];
>> char ch;
>> int
>> main ()
>> {
>>    return data_start < &ch;
>> }
>
> No, this gives the "undefined reference to `_data_start'" error.  Making
> that change in configure.ac fixes the problem.

I went ahead and committed this change as bzr revision 111889.  I'm 
closing the bug.

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.