GNU bug report logs - #9492
cannot override CC when using system copy of libtool ("The wrong-gcc problem")

Previous Next

To reply to this bug, email your comments to 9492 AT debbugs.gnu.org.

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

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

From: Рубен Бучацкий
	<ruben.buchatskiy <at> gmail.com>
To: bug-libtool <at> gnu.org
Subject: The wrong-gcc problem
Date: Tue, 13 Sep 2011 17:43:01 +0400

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

Hello!

I'm building Sqlite 3.7.7.1 with libtool 2.4. I'm doing the cross
compile. Configuring sqlite with CC="my compiler". In compilation mode
everything is ok, but when I link, libtool tries to call the native
gcc (in spite of the fact, that CC="my compiler", not native).

*~/libtool-2.4/libtool* --tag=CC --mode=link *
/home/ruben/x-tools/gcc-trunk-clean/bin/arm-unknown-linux-gnueabi-gcc*   -O2
-mcpu=cortex-a8 -mtune=cortex-a8 -mfloat-abi=softfp -mfpu=neon -mthumb -flto
-DSQLITE_OS_UNIX=1 -I. -I./src -I./ext/rtree -D_HAVE_SQLITE_CONFIG_H
-DNDEBUG   -DSQLITE_THREADSAFE=1 -DSQLITE_OMIT_LOAD_EXTENSION=1     -o
libsqlite3.la alter.lo analyze.lo attach.lo auth.lo backup.lo bitvec.lo
btmutex.lo btree.lo build.lo callback.lo complete.lo ctime.lo date.lo
delete.lo expr.lo fault.lo fkey.lo fts3.lo fts3_aux.lo fts3_expr.lo
fts3_hash.lo fts3_icu.lo fts3_porter.lo fts3_snippet.lo fts3_tokenizer.lo
fts3_tokenizer1.lo fts3_write.lo func.lo global.lo hash.lo icu.lo insert.lo
journal.lo legacy.lo loadext.lo main.lo malloc.lo mem0.lo mem1.lo mem2.lo
mem3.lo mem5.lo memjournal.lo mutex.lo mutex_noop.lo mutex_os2.lo
mutex_unix.lo mutex_w32.lo notify.lo opcodes.lo os.lo os_os2.lo os_unix.lo
os_win.lo pager.lo parse.lo pcache.lo pcache1.lo pragma.lo prepare.lo
printf.lo random.lo resolve.lo rowset.lo rtree.lo select.lo status.lo
table.lo tokenize.lo trigger.lo update.lo util.lo vacuum.lo vdbe.lo
vdbeapi.lo vdbeaux.lo vdbeblob.lo vdbemem.lo vdbetrace.lo wal.lo walker.lo
where.lo utf.lo vtab.lo -lpthread  \
 -rpath "/home/ruben/condor/testings/sqlitesrc/sqlite-src-3070701/build/lib"
-version-info "8:6:8"
libtool: link: *gcc* -shared  -fPIC -DPIC  .libs/alter.o .libs/analyze.o
.libs/attach.o .libs/auth.o .libs/backup.o .libs/bitvec.o .libs/btmutex.o
.libs/btree.o .libs/build.o .libs/callback.o .libs/complete.o .libs/ctime.o
.libs/date.o .libs/delete.o .libs/expr.o .libs/fault.o .libs/fkey.o
.libs/fts3.o .libs/fts3_aux.o .libs/fts3_expr.o .libs/fts3_hash.o
.libs/fts3_icu.o .libs/fts3_porter.o .libs/fts3_snippet.o
.libs/fts3_tokenizer.o .libs/fts3_tokenizer1.o .libs/fts3_write.o
.libs/func.o .libs/global.o .libs/hash.o .libs/icu.o .libs/insert.o
.libs/journal.o .libs/legacy.o .libs/loadext.o .libs/main.o .libs/malloc.o
.libs/mem0.o .libs/mem1.o .libs/mem2.o .libs/mem3.o .libs/mem5.o
.libs/memjournal.o .libs/mutex.o .libs/mutex_noop.o .libs/mutex_os2.o
.libs/mutex_unix.o .libs/mutex_w32.o .libs/notify.o .libs/opcodes.o
.libs/os.o .libs/os_os2.o .libs/os_unix.o .libs/os_win.o .libs/pager.o
.libs/parse.o .libs/pcache.o .libs/pcache1.o .libs/pragma.o .libs/prepare.o
.libs/printf.o .libs/random.o .libs/resolve.o .libs/rowset.o .libs/rtree.o
.libs/select.o .libs/status.o .libs/table.o .libs/tokenize.o .libs/trigger.o
.libs/update.o .libs/util.o .libs/vacuum.o .libs/vdbe.o .libs/vdbeapi.o
.libs/vdbeaux.o .libs/vdbeblob.o .libs/vdbemem.o .libs/vdbetrace.o
.libs/wal.o .libs/walker.o .libs/where.o .libs/utf.o .libs/vtab.o
-lpthread  -O2 -mcpu=cortex-a8 -mtune=cortex-a8 -mfloat-abi=softfp
-mfpu=neon -mthumb -flto  -Wl,-soname -Wl,libsqlite3.so.0 -o
.libs/libsqlite3.so.0.8.6
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/alter.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/analyze.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/attach.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/auth.o' is incompatible with
i386:x86-64 output
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld:
arm architecture of input file `.libs/backup.o' is incompatible with
i386:x86-64 output
...............................................................

The solution is to configure libtool by setting CC="my compiler". But
it's not good. I'm not good in m4 scripting, but in attached file is
that, what I changed in configure of libtool. In the old version of
libtool(2.2.6) everything is good. I'm using new libtool, because it
supports LTO.

some links about this problem:

http://www.mail-archive.com/libtool <at> gnu.org/msg11262.html

http://metastatic.org/text/libtool.html

 --
*С уважением,
**Бучацкий Р.А.* <ruben.buchatskiy <at> gmail.com>

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

[configure_patch.diff (text/x-patch, attachment)]

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: 9492 <at> debbugs.gnu.org
Cc: Jonathan Nieder <jrnieder <at> gmail.com>,
 Рубен Бучацкий
 <ruben.buchatskiy <at> gmail.com>
Subject: Re: bug#9492: cannot override CC when using system copy of libtool
 ("The wrong-gcc problem")
Date: Sun, 13 Oct 2024 23:01:02 +0900

Hello,

Just a heads-up that this old bug is still relevant.  It means that one
cannot use libtool stand-alone (without Autotools) and expect
cross-compilation or even just switching temporarily compilers
(e.g. from 'gcc' to 'clang' via CC to test something).  Heres' what the
failure look like:

--8<---------------cut here---------------start------------->8---
libtool: link: gcc -shared  -fPIC -DPIC  build/obj/Core/.libs/apu.c.o build/obj/Core/.libs/camera.c.o build/obj/Core/.libs/cheats.c.o build/obj/Core/.libs/debugger.c.o build/obj/Core/.libs/display.c.o build/obj/Core/.libs/gb.c.o build/obj/Core/.libs/joypad.c.o build/obj/Core/.libs/mbc.c.o build/obj/Core/.libs/memory.c.o build/obj/Core/.libs/printer.c.o build/obj/Core/.libs/random.c.o build/obj/Core/.libs/rewind.c.o build/obj/Core/.libs/rumble.c.o build/obj/Core/.libs/save_state.c.o build/obj/Core/.libs/sgb.c.o build/obj/Core/.libs/sm83_cpu.c.o build/obj/Core/.libs/sm83_disassembler.c.o build/obj/Core/.libs/symbol_hash.c.o build/obj/Core/.libs/timing.c.o build/obj/Core/.libs/workboy.c.o      -Wl,-soname -Wl,libsameboy.so.0 -o build/lib/.libs/libsameboy.so.0.0.0
/gnu/store/gpq3h81bzjpirwnc0fzwsph788b9rwn4-libtool-2.5.3/bin/libtool: line 10778: gcc: command not found
make: *** [Makefile:832: build/lib/libsameboy.la] Error 127
make: *** Waiting for unfinished jobs....
error: in phase 'build': uncaught exception:
--8<---------------cut here---------------end--------------->8---


That's when building some Make-based software that calls libtool
directly.  Here, the libtool version was built with GCC (has baked
CC="gcc" variable around line 326), which is what it uses when linking
with its $archive_cmds variable defined a bit later (line 368):

--8<---------------cut here---------------start------------->8---
archive_cmds="\$CC -shared \$pic_flag \$libobjs \$deplibs \$compiler_flags \$wl-soname \$wl\$soname -o \$lib"
--8<---------------cut here---------------end--------------->8---

Seems this should be able to fix?  Check for environment CC, if not set,
defaults to gcc?  Would this simple fix be enough?

-- 
Thanks,
Maxim

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

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: 9492 <at> debbugs.gnu.org
Cc: Jonathan Nieder <jrnieder <at> gmail.com>,
 Рубен Бучацкий
 <ruben.buchatskiy <at> gmail.com>, Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Subject: Re: bug#9492: cannot override CC when using system copy of libtool
 ("The wrong-gcc problem")
Date: Wed, 16 Oct 2024 22:47:44 +0300

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

On 13/10/2024 17:01, Maxim Cournoyer wrote:
> Hello,
> 
> Just a heads-up that this old bug is still relevant.  It means that one
> cannot use libtool stand-alone (without Autotools) and expect
> cross-compilation or even just switching temporarily compilers
> (e.g. from 'gcc' to 'clang' via CC to test something).  Heres' what the
> failure look like:
> 
> --8<---------------cut here---------------start------------->8---
> libtool: link: gcc -shared  -fPIC -DPIC  build/obj/Core/.libs/apu.c.o build/obj/Core/.libs/camera.c.o build/obj/Core/.libs/cheats.c.o build/obj/Core/.libs/debugger.c.o build/obj/Core/.libs/display.c.o build/obj/Core/.libs/gb.c.o build/obj/Core/.libs/joypad.c.o build/obj/Core/.libs/mbc.c.o build/obj/Core/.libs/memory.c.o build/obj/Core/.libs/printer.c.o build/obj/Core/.libs/random.c.o build/obj/Core/.libs/rewind.c.o build/obj/Core/.libs/rumble.c.o build/obj/Core/.libs/save_state.c.o build/obj/Core/.libs/sgb.c.o build/obj/Core/.libs/sm83_cpu.c.o build/obj/Core/.libs/sm83_disassembler.c.o build/obj/Core/.libs/symbol_hash.c.o build/obj/Core/.libs/timing.c.o build/obj/Core/.libs/workboy.c.o      -Wl,-soname -Wl,libsameboy.so.0 -o build/lib/.libs/libsameboy.so.0.0.0
> /gnu/store/gpq3h81bzjpirwnc0fzwsph788b9rwn4-libtool-2.5.3/bin/libtool: line 10778: gcc: command not found
> make: *** [Makefile:832: build/lib/libsameboy.la] Error 127
> make: *** Waiting for unfinished jobs....
> error: in phase 'build': uncaught exception:
> --8<---------------cut here---------------end--------------->8---

I have not been able to reproduce overriding CC in libtool 2.2.6, but I
do not think it would be good practice to do.

> That's when building some Make-based software that calls libtool
> directly.  Here, the libtool version was built with GCC (has baked
> CC="gcc" variable around line 326), which is what it uses when linking
> with its $archive_cmds variable defined a bit later (line 368):
> 
> --8<---------------cut here---------------start------------->8---
> archive_cmds="\$CC -shared \$pic_flag \$libobjs \$deplibs \$compiler_flags \$wl-soname \$wl\$soname -o \$lib"
> --8<---------------cut here---------------end--------------->8---
> 
> Seems this should be able to fix?  Check for environment CC, if not set,
> defaults to gcc?  Would this simple fix be enough?
> 

If CC is conditional, other configuration would also need to be
conditional for the C compiler set. I have attached two versions of
libtool, one with CC=gcc and the other with CC=clang. When diffing them
you can see the other variables that would need to be updated if CC was
updated at runtime for libtool.

If you want to do a quick test and change CC, you can edit the generated
libtool to do this and then revert the change after your test. However,
you could also generate multiple standalone versions of libtool and
switch which is referenced so that the other configuration variables are
set properly.

I would consider this to be more of a feature request than a bug with
libtool to allow for defaults set during configuration to be updated,
but there may be files other than libtool generated during configuration
that would also need to be updated. Generally, I recommend reconfiguring
your project whenever CC is changed.

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[libtool-clang (text/plain, attachment)]

[libtool-gcc (text/plain, attachment)]

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

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

From: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
To: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
Cc: 9492 <at> debbugs.gnu.org, Jonathan Nieder <jrnieder <at> gmail.com>,
 Рубен Бучацкий
 <ruben.buchatskiy <at> gmail.com>
Subject: Re: bug#9492: cannot override CC when using system copy of libtool
 ("The wrong-gcc problem")
Date: Sat, 19 Oct 2024 22:57:59 +0900

Hello Ileana,

Ileana Dumitrescu <endometriosis95 <at> gmail.com> writes:

> On 13/10/2024 17:01, Maxim Cournoyer wrote:
>> Hello,
>> Just a heads-up that this old bug is still relevant.  It means that
>> one
>> cannot use libtool stand-alone (without Autotools) and expect
>> cross-compilation or even just switching temporarily compilers
>> (e.g. from 'gcc' to 'clang' via CC to test something).  Heres' what the
>> failure look like:
>> --8<---------------cut here---------------start------------->8---
>> libtool: link: gcc -shared -fPIC -DPIC build/obj/Core/.libs/apu.c.o
>> build/obj/Core/.libs/camera.c.o build/obj/Core/.libs/cheats.c.o
>> build/obj/Core/.libs/debugger.c.o build/obj/Core/.libs/display.c.o
>> build/obj/Core/.libs/gb.c.o build/obj/Core/.libs/joypad.c.o
>> build/obj/Core/.libs/mbc.c.o build/obj/Core/.libs/memory.c.o
>> build/obj/Core/.libs/printer.c.o build/obj/Core/.libs/random.c.o
>> build/obj/Core/.libs/rewind.c.o build/obj/Core/.libs/rumble.c.o
>> build/obj/Core/.libs/save_state.c.o build/obj/Core/.libs/sgb.c.o
>> build/obj/Core/.libs/sm83_cpu.c.o
>> build/obj/Core/.libs/sm83_disassembler.c.o
>> build/obj/Core/.libs/symbol_hash.c.o build/obj/Core/.libs/timing.c.o
>> build/obj/Core/.libs/workboy.c.o -Wl,-soname -Wl,libsameboy.so.0 -o
>> build/lib/.libs/libsameboy.so.0.0.0
>> /gnu/store/gpq3h81bzjpirwnc0fzwsph788b9rwn4-libtool-2.5.3/bin/libtool: line 10778: gcc: command not found
>> make: *** [Makefile:832: build/lib/libsameboy.la] Error 127
>> make: *** Waiting for unfinished jobs....
>> error: in phase 'build': uncaught exception:
>> --8<---------------cut here---------------end--------------->8---
>
> I have not been able to reproduce overriding CC in libtool 2.2.6, but I
> do not think it would be good practice to do.

That's what I've been told elsewhere too.  Hence my interest in having
libtool support it, if that's not too difficult.

>> That's when building some Make-based software that calls libtool
>> directly.  Here, the libtool version was built with GCC (has baked
>> CC="gcc" variable around line 326), which is what it uses when linking
>> with its $archive_cmds variable defined a bit later (line 368):
>> --8<---------------cut here---------------start------------->8---
>> archive_cmds="\$CC -shared \$pic_flag \$libobjs \$deplibs \$compiler_flags \$wl-soname \$wl\$soname -o \$lib"
>> --8<---------------cut here---------------end--------------->8---
>> Seems this should be able to fix?  Check for environment CC, if not
>> set,
>> defaults to gcc?  Would this simple fix be enough?
>> 
>
> If CC is conditional, other configuration would also need to be
> conditional for the C compiler set. I have attached two versions of
> libtool, one with CC=gcc and the other with CC=clang. When diffing them
> you can see the other variables that would need to be updated if CC was
> updated at runtime for libtool.
>
> If you want to do a quick test and change CC, you can edit the generated
> libtool to do this and then revert the change after your test. However,
> you could also generate multiple standalone versions of libtool and
> switch which is referenced so that the other configuration variables are
> set properly.
>
> I would consider this to be more of a feature request than a bug with
> libtool to allow for defaults set during configuration to be updated,
> but there may be files other than libtool generated during configuration
> that would also need to be updated. Generally, I recommend reconfiguring
> your project whenever CC is changed.

The libtool manual doesn't outright says that libtool should NOT be used
standalone. It doesn't warn against the current gotchas (cannot change
CC, cannot cross-compile). Hence I'd perhaps consider it a bug.

I'll see if I can get to some required level of M4-foo to attempt some
partial fix (to get started). I've been trying stuff but without success
so far, due to the layering of M4 then shell script and still being a
bit unclear on the expansion order/variables used.

Thank you.

-- 
Maxim

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

From: Ileana Dumitrescu <ileanadumitrescu95 <at> gmail.com>
To: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>
Cc: 9492 <at> debbugs.gnu.org, Jonathan Nieder <jrnieder <at> gmail.com>,
 Рубен Бучацкий
 <ruben.buchatskiy <at> gmail.com>
Subject: Re: bug#9492: cannot override CC when using system copy of libtool
 ("The wrong-gcc problem")
Date: Mon, 21 Oct 2024 18:22:20 +0300

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

On 19/10/2024 16:57, Maxim Cournoyer wrote:
> Hello Ileana,
> 
> Ileana Dumitrescu <endometriosis95 <at> gmail.com> writes:
> 
>> On 13/10/2024 17:01, Maxim Cournoyer wrote:
>>> Hello,
>>> Just a heads-up that this old bug is still relevant.  It means that
>>> one
>>> cannot use libtool stand-alone (without Autotools) and expect
>>> cross-compilation or even just switching temporarily compilers
>>> (e.g. from 'gcc' to 'clang' via CC to test something).  Heres' what the
>>> failure look like:
>>> --8<---------------cut here---------------start------------->8---
>>> libtool: link: gcc -shared -fPIC -DPIC build/obj/Core/.libs/apu.c.o
>>> build/obj/Core/.libs/camera.c.o build/obj/Core/.libs/cheats.c.o
>>> build/obj/Core/.libs/debugger.c.o build/obj/Core/.libs/display.c.o
>>> build/obj/Core/.libs/gb.c.o build/obj/Core/.libs/joypad.c.o
>>> build/obj/Core/.libs/mbc.c.o build/obj/Core/.libs/memory.c.o
>>> build/obj/Core/.libs/printer.c.o build/obj/Core/.libs/random.c.o
>>> build/obj/Core/.libs/rewind.c.o build/obj/Core/.libs/rumble.c.o
>>> build/obj/Core/.libs/save_state.c.o build/obj/Core/.libs/sgb.c.o
>>> build/obj/Core/.libs/sm83_cpu.c.o
>>> build/obj/Core/.libs/sm83_disassembler.c.o
>>> build/obj/Core/.libs/symbol_hash.c.o build/obj/Core/.libs/timing.c.o
>>> build/obj/Core/.libs/workboy.c.o -Wl,-soname -Wl,libsameboy.so.0 -o
>>> build/lib/.libs/libsameboy.so.0.0.0
>>> /gnu/store/gpq3h81bzjpirwnc0fzwsph788b9rwn4-libtool-2.5.3/bin/libtool: line 10778: gcc: command not found
>>> make: *** [Makefile:832: build/lib/libsameboy.la] Error 127
>>> make: *** Waiting for unfinished jobs....
>>> error: in phase 'build': uncaught exception:
>>> --8<---------------cut here---------------end--------------->8---
>>
>> I have not been able to reproduce overriding CC in libtool 2.2.6, but I
>> do not think it would be good practice to do.
> 
> That's what I've been told elsewhere too.  Hence my interest in having
> libtool support it, if that's not too difficult.
> 
>>> That's when building some Make-based software that calls libtool
>>> directly.  Here, the libtool version was built with GCC (has baked
>>> CC="gcc" variable around line 326), which is what it uses when linking
>>> with its $archive_cmds variable defined a bit later (line 368):
>>> --8<---------------cut here---------------start------------->8---
>>> archive_cmds="\$CC -shared \$pic_flag \$libobjs \$deplibs \$compiler_flags \$wl-soname \$wl\$soname -o \$lib"
>>> --8<---------------cut here---------------end--------------->8---
>>> Seems this should be able to fix?  Check for environment CC, if not
>>> set,
>>> defaults to gcc?  Would this simple fix be enough?
>>>
>>
>> If CC is conditional, other configuration would also need to be
>> conditional for the C compiler set. I have attached two versions of
>> libtool, one with CC=gcc and the other with CC=clang. When diffing them
>> you can see the other variables that would need to be updated if CC was
>> updated at runtime for libtool.
>>
>> If you want to do a quick test and change CC, you can edit the generated
>> libtool to do this and then revert the change after your test. However,
>> you could also generate multiple standalone versions of libtool and
>> switch which is referenced so that the other configuration variables are
>> set properly.
>>
>> I would consider this to be more of a feature request than a bug with
>> libtool to allow for defaults set during configuration to be updated,
>> but there may be files other than libtool generated during configuration
>> that would also need to be updated. Generally, I recommend reconfiguring
>> your project whenever CC is changed.
> 
> The libtool manual doesn't outright says that libtool should NOT be used
> standalone. It doesn't warn against the current gotchas (cannot change
> CC, cannot cross-compile). Hence I'd perhaps consider it a bug.

This section of the libtool manual should help you understand how to use
a system-specific libtool script installed in your binary directory:
https://www.gnu.org/software/libtool/manual/libtool.html#Configuring-libtool

libtool can be used standalone as long as it has been configured for the
"compiler suite and operating system that are used to compile your
package." Cross-compilation is also possible if libtool has been
configured to do it.

To allow CC to be overridden, libtool would not set all of the
configuration variables it needs for the newly set compiler, so it would
not operate correctly. libtool would need to reconfigure itself if CC
was changed during execution... This might be possible if an option was
added to libtool to reconfigure itself, but I am open to other
suggestions for ways to approach making libtool more dynamic for users.

> I'll see if I can get to some required level of M4-foo to attempt some
> partial fix (to get started). I've been trying stuff but without success
> so far, due to the layering of M4 then shell script and still being a
> bit unclear on the expansion order/variables used.
> 
> Thank you.
> 

-- 
Ileana Dumitrescu

GPG Public Key: FA26 CA78 4BE1 8892 7F22 B99F 6570 EA01 146F 7354

[OpenPGP_0x6570EA01146F7354.asc (application/pgp-keys, attachment)]

[OpenPGP_signature.asc (application/pgp-signature, attachment)]

Previous Next

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