GNU bug report logs - #37852
Build failure on MSYS2 (undefined reference to _chk functions)

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 37852 in the body.
You can then email your comments to 37852 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: Richard Copley <rcopley <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Build failure on MSYS2 (undefined reference to _chk functions)
Date: Mon, 21 Oct 2019 13:28:29 +0100

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

 Linking auxiliary executables fails with undefined references to
(FORTIFY_SOURCE?) functions  __memcpy_chk and __memmove_chk. This is
apparently caused by some change in MSYS2, because previously buildable
commits now fail. Transcript below.

+ make V=1 -k
make -C nt all
make[1]: Entering directory '/c/projects/emacs/nt'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/projects/emacs/nt'
make -C lib all
make[1]: Entering directory '/c/projects/emacs/lib'
make[1]: Nothing to be done for 'all'.
make[1]: Leaving directory '/c/projects/emacs/lib'
make -C lib-src all
make[1]: Entering directory '/c/projects/emacs/lib-src'
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 emacsclient.c \
   ntlib.o ../lib/libgnu.a  \
   -lwsock32  -lcomctl32 -o emacsclient.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccVJXdYZ.o:emacsclient.c:(.text+0xb4d):
undefined reference to `__memmove_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:395: emacsclient.exe] Error 1
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 emacsclient.res -mwindows emacsclient.c \
   ../lib/libgnu.a  \
   -lwsock32  -lcomctl32 -o emacsclientw.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccSZs6xf.o:emacsclient.c:(.text+0xb4d):
undefined reference to `__memmove_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:400: emacsclientw.exe] Error 1
gcc  -mtune=generic  -fno-common -W[...]  -I. -I../src -I../lib -I.
-I./../src -I./../lib   -mtune=generic   -DUSE_CRT_DLL=1 -I
/c/projects/emacs/nt/inc -O2 make-docfile.c ntlib.o ../lib/libgnu.a  -o
make-docfile.exe
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/9.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
C:\Users\buster\AppData\Local\Temp\ccHhbMkg.o:make-docfile.c:(.text+0x166a):
undefined reference to `__memcpy_chk'
collect2.exe: error: ld returned 1 exit status
make[1]: *** [Makefile:382: make-docfile.exe] Error 1
make[1]: Target 'all' not remade because of errors.
make[1]: Leaving directory '/c/projects/emacs/lib-src'
make: *** [Makefile:411: lib-src] Error 2
make info-real info-dir
make[1]: Entering directory '/c/projects/emacs'
make -C doc/lispref info
make[2]: Entering directory '/c/projects/emacs/doc/lispref'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/lispref'
make -C doc/lispintro info
make[2]: Entering directory '/c/projects/emacs/doc/lispintro'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/lispintro'
make -C doc/emacs info
make[2]: Entering directory '/c/projects/emacs/doc/emacs'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/emacs'
make -C doc/misc info
make[2]: Entering directory '/c/projects/emacs/doc/misc'
make[2]: Nothing to be done for 'info'.
make[2]: Leaving directory '/c/projects/emacs/doc/misc'
make[1]: Nothing to be done for 'info-dir'.
make[1]: Leaving directory '/c/projects/emacs'
make: Target 'all' not remade because of errors.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 16:07:34 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Mon, 21 Oct 2019 13:28:29 +0100
> 
> Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
> __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2, because
> previously buildable commits now fail. Transcript below.

Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
adding that, e.g. by

  make LIBS_SYSTEM=-lssp

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 14:17:36 +0100

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

On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Richard Copley <rcopley <at> gmail.com>
> > Date: Mon, 21 Oct 2019 13:28:29 +0100
> >
> > Linking auxiliary executables fails with undefined references to
> (FORTIFY_SOURCE?) functions
> > __memcpy_chk and __memmove_chk. This is apparently caused by some change
> in MSYS2, because
> > previously buildable commits now fail. Transcript below.
>
> Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
> adding that, e.g. by
>
>   make LIBS_SYSTEM=-lssp
>

Yes, that works.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 16:31:56 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Mon, 21 Oct 2019 14:17:36 +0100
> Cc: 37852 <at> debbugs.gnu.org
> 
> On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Richard Copley <rcopley <at> gmail.com>
>  > Date: Mon, 21 Oct 2019 13:28:29 +0100
>  > 
>  > Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
>  > __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2,
>  because
>  > previously buildable commits now fail. Transcript below.
> 
>  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
>  adding that, e.g. by
> 
>    make LIBS_SYSTEM=-lssp
> 
> Yes, that works.

OK, thanks.

So do we need to add that library to the link command under some
conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
configure script (in which case I'm missing something, because I
didn't find it in the configure script), or is this an option you
added manually?  In the latter case, would configuring with LIBS=-lssp
be an okay solution?

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 15:04:34 +0100

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

On Mon, 21 Oct 2019 at 14:32, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Richard Copley <rcopley <at> gmail.com>
> > Date: Mon, 21 Oct 2019 14:17:36 +0100
> > Cc: 37852 <at> debbugs.gnu.org
> >
> > On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >
> >  > From: Richard Copley <rcopley <at> gmail.com>
> >  > Date: Mon, 21 Oct 2019 13:28:29 +0100
> >  >
> >  > Linking auxiliary executables fails with undefined references to
> (FORTIFY_SOURCE?) functions
> >  > __memcpy_chk and __memmove_chk. This is apparently caused by some
> change in MSYS2,
> >  because
> >  > previously buildable commits now fail. Transcript below.
> >
> >  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
> >  adding that, e.g. by
> >
> >    make LIBS_SYSTEM=-lssp
> >
> > Yes, that works.
>
> OK, thanks.
>
> So do we need to add that library to the link command under some
> conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> configure script (in which case I'm missing something, because I
> didn't find it in the configure script),
>

I don't know.


> or is this an option you
> added manually?
>

No, I built in a clean checkout of master, with these commands:

./autogen.sh
./configure --without-pop --without-dbus --without-gconf
--without-gsettings "CFLAGS=-O2"
make

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 19:01:20 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Mon, 21 Oct 2019 15:04:34 +0100
> Cc: 37852 <at> debbugs.gnu.org
> 
>  or is this an option you
>  added manually?
> 
> No, I built in a clean checkout of master, with these commands:
> 
> ./autogen.sh
> ./configure --without-pop --without-dbus --without-gconf --without-gsettings "CFLAGS=-O2"
> make

Hmm... okay, could you please grep Makefiles in lib-src/ and src/, and
see if FORTIFY_SOURCE appears in any of them?  If not, I guess the
references to those _chk functions are coming from some libraries
linked into the programs we compile, and that probably means we need
to use -lssp for MinGW just in case?

Possibly relevant discussion:

  https://github.com/msys2/MINGW-packages/issues/5803

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

From: Andy Moreton <andrewjmoreton <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 17:05:35 +0100

On Mon 21 Oct 2019, Eli Zaretskii wrote:

>> From: Richard Copley <rcopley <at> gmail.com>
>> Date: Mon, 21 Oct 2019 14:17:36 +0100
>> Cc: 37852 <at> debbugs.gnu.org
>> 
>> On Mon, 21 Oct 2019 at 14:07, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>  > From: Richard Copley <rcopley <at> gmail.com>
>>  > Date: Mon, 21 Oct 2019 13:28:29 +0100
>>  > 
>>  > Linking auxiliary executables fails with undefined references to (FORTIFY_SOURCE?) functions 
>>  > __memcpy_chk and __memmove_chk. This is apparently caused by some change in MSYS2,
>>  because
>>  > previously buildable commits now fail. Transcript below.
>> 
>>  Looks like FORTIFY_SOURCE requires linking against -lssp?  Can you try
>>  adding that, e.g. by
>> 
>>    make LIBS_SYSTEM=-lssp
>> 
>> Yes, that works.
>
> OK, thanks.
>
> So do we need to add that library to the link command under some
> conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> configure script (in which case I'm missing something, because I
> didn't find it in the configure script), or is this an option you
> added manually?  In the latter case, would configuring with LIBS=-lssp
> be an okay solution?

See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
is _FORTIFY_SOURCE.

Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
the missing library is a better workaround than disabling the checks.

    AndyM

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andy Moreton <andrewjmoreton <at> gmail.com>
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 19:36:17 +0300

> From: Andy Moreton <andrewjmoreton <at> gmail.com>
> Date: Mon, 21 Oct 2019 17:05:35 +0100
> 
> > So do we need to add that library to the link command under some
> > conditions?  IOW, is FORTIFY_SOURCE something that comes out of our
> > configure script (in which case I'm missing something, because I
> > didn't find it in the configure script), or is this an option you
> > added manually?  In the latter case, would configuring with LIBS=-lssp
> > be an okay solution?
> 
> See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
> is _FORTIFY_SOURCE.

Thanks, I indeed missed that.

> Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
> the missing library is a better workaround than disabling the checks.

The problem with using -lssp unconditionally is that some
installations might not have it, and then the linker will barf.  So I
think we should better disable GNULIB_PORTCHECK on MinGW (I can hardly
imagine someone using that platform for those portability checks, and
I'm not sure I understand why this gets defined by default on other
platforms).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: andrewjmoreton <at> gmail.com
Cc: 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 19:55:49 +0300

> Date: Mon, 21 Oct 2019 19:36:17 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 37852 <at> debbugs.gnu.org
> 
> > See GNULIB_PORTCHECK_FORTIFY_SOURCE in configure.ac - the relevant macro
> > is _FORTIFY_SOURCE.
> 
> Thanks, I indeed missed that.
> 
> > Building with -D_FORTIFY_SOURCE=0 also works, but your suggestion to add
> > the missing library is a better workaround than disabling the checks.

Btw, this sounds like a bug in MinGW64 headers: they shouldn't
generate references to the _chk functions without making sure,
e.g. via specs or somesuch, that libssp is linked against.  It's worth
reporting to the MSYS2 folks, I think.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Richard Copley <rcopley <at> gmail.com>, 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Mon, 21 Oct 2019 17:40:12 -0700

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

> I think we should better disable GNULIB_PORTCHECK on MinGW (I can hardly
> imagine someone using that platform for those portability checks, and
> I'm not sure I understand why this gets defined by default on other
> platforms).

The intent of GNULIB_PORTCHECK is that it is enabled by developers who 
want some simple build-time portability tests. It isn't suitable for 
people who just want to build the software, as there are too many build 
failures and other false alarms that builders don't care about.

I installed the attached patch, to cause the problem to occur only if 
one configures explicitly with --enable-gcc-warnings. This should fix 
the problem that Richard reported. However, it won't fix the more 
general problem (which Richard should be able to reproduce via 
'./configure --enable-gcc-warnings ...').

Apparently MSYS2 changed recently, and this caused _FORTIFY_SOURCE 
builds to fail. See, for example:

https://github.com/msys2/MINGW-packages/issues/5803

I don't understand MSYS2 well enough to suggest fixes for Emacs, other 
than "don't configure with --enable-gcc-warnings and don't compile with 
_FORTIFY_SOURCE defined".

[0001-Portcheck-only-if-enable-gcc-warnings.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rcopley <at> gmail.com, 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Tue, 22 Oct 2019 05:37:53 +0300

> Cc: 37852 <at> debbugs.gnu.org, Richard Copley <rcopley <at> gmail.com>
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Mon, 21 Oct 2019 17:40:12 -0700
> 
> I installed the attached patch, to cause the problem to occur only if 
> one configures explicitly with --enable-gcc-warnings. This should fix 
> the problem that Richard reported.

Thanks.

> I don't understand MSYS2 well enough to suggest fixes for Emacs, other 
> than "don't configure with --enable-gcc-warnings and don't compile with 
> _FORTIFY_SOURCE defined".

Should we perhaps test for -lssp, and if it is found, add it to the
link command when we define _FORTIFY_SOURCE?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rcopley <at> gmail.com, 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Tue, 22 Oct 2019 11:27:48 -0700

On 10/21/19 7:37 PM, Eli Zaretskii wrote:

>> I don't understand MSYS2 well enough to suggest fixes for Emacs, other
>> than "don't configure with --enable-gcc-warnings and don't compile with
>> _FORTIFY_SOURCE defined".
> 
> Should we perhaps test for -lssp, and if it is found, add it to the
> link command when we define _FORTIFY_SOURCE?

If this is done only on MSYS2 platforms, and if -lssp is used only when 
it causes otherwise-failing programs to work, then it should be OK. I 
wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be 
trouble and was best avoided.

It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing 
problems Fedora had a few years ago (see, e.g., 
<https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rcopley <at> gmail.com, 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Tue, 22 Oct 2019 21:51:00 +0300

> Cc: 37852 <at> debbugs.gnu.org, rcopley <at> gmail.com
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 22 Oct 2019 11:27:48 -0700
> 
> > Should we perhaps test for -lssp, and if it is found, add it to the
> > link command when we define _FORTIFY_SOURCE?
> 
> If this is done only on MSYS2 platforms, and if -lssp is used only when 
> it causes otherwise-failing programs to work, then it should be OK. I 
> wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be 
> trouble and was best avoided.

Right.

> It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing 
> problems Fedora had a few years ago (see, e.g., 
> <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).

I actually think it's a bug in MSYS2, and hope they will fix it soon.
So perhaps we should just wait and see if the current situation, after
your patch, is good enough.

Thanks.

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

From: Richard Copley <rcopley <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 37852 <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Wed, 23 Oct 2019 22:29:09 +0100

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

On Tue, 22 Oct 2019 at 19:51, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: 37852 <at> debbugs.gnu.org, rcopley <at> gmail.com
> > From: Paul Eggert <eggert <at> cs.ucla.edu>
> > Date: Tue, 22 Oct 2019 11:27:48 -0700
> >
> > > Should we perhaps test for -lssp, and if it is found, add it to the
> > > link command when we define _FORTIFY_SOURCE?
> >
> > If this is done only on MSYS2 platforms, and if -lssp is used only when
> > it causes otherwise-failing programs to work, then it should be OK. I
> > wouldn't do it elsewhere because on Fedora at any rate, -lssp used to be
> > trouble and was best avoided.
>
> Right.
>
> > It vaguely sounds like MSYS2 is trailing Fedora and so is experiencing
> > problems Fedora had a few years ago (see, e.g.,
> > <https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2016-4973>).
>
> I actually think it's a bug in MSYS2, and hope they will fix it soon.
> So perhaps we should just wait and see if the current situation, after
> your patch, is good enough.
>
> Thanks.
>

Just to confirm, this fix works for me. Thank you.

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Richard Copley <rcopley <at> gmail.com>
Cc: eggert <at> cs.ucla.edu, 37852-done <at> debbugs.gnu.org
Subject: Re: bug#37852: Build failure on MSYS2 (undefined reference to _chk
 functions)
Date: Thu, 24 Oct 2019 16:50:25 +0300

> From: Richard Copley <rcopley <at> gmail.com>
> Date: Wed, 23 Oct 2019 22:29:09 +0100
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 37852 <at> debbugs.gnu.org
> 
> Just to confirm, this fix works for me. Thank you.

Thanks, closing.

Previous Next

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