GNU bug report logs - #37801
Possible insight into issue #30756 #include_next bug

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guix; Reported by: Carl Dong <contact@HIDDEN>; dated Thu, 17 Oct 2019 21:58:02 UTC; Maintainer for guix is bug-guix@HIDDEN.

Message received at 37801 <at> debbugs.gnu.org:


Received: (at 37801) by debbugs.gnu.org; 19 Oct 2019 12:53:48 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Oct 19 08:53:48 2019
Received: from localhost ([127.0.0.1]:52087 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iLoEu-0004s8-Gi
	for submit <at> debbugs.gnu.org; Sat, 19 Oct 2019 08:53:48 -0400
Received: from dd26836.kasserver.com ([85.13.145.193]:38652)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dannym@HIDDEN>) id 1iLoEs-0004s0-AL
 for 37801 <at> debbugs.gnu.org; Sat, 19 Oct 2019 08:53:47 -0400
Received: from localhost (unknown [185.17.13.127])
 by dd26836.kasserver.com (Postfix) with ESMTPSA id 0DC7833655A5;
 Sat, 19 Oct 2019 14:53:45 +0200 (CEST)
Date: Sat, 19 Oct 2019 14:53:36 +0200
From: Danny Milosavljevic <dannym@HIDDEN>
To: Carl Dong <contact@HIDDEN>
Subject: Re: bug#37801: Possible insight into issue #30756 #include_next bug
Message-ID: <20191019145336.4fb5af37@HIDDEN>
In-Reply-To: <H5R52pYX-v7FYakGyXf-DjdVXYEMCTAR211IyaKX1lZ2haUGvm22ZfH8fRu1u8LWJPMCGhmUmvufVp43KseEbK69HVcAWfi0sKpuZkUEA4k=@carldong.me>
References: <xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me>
 <20191018020344.78cbee48@HIDDEN>
 <H5R52pYX-v7FYakGyXf-DjdVXYEMCTAR211IyaKX1lZ2haUGvm22ZfH8fRu1u8LWJPMCGhmUmvufVp43KseEbK69HVcAWfi0sKpuZkUEA4k=@carldong.me>
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-unknown-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/Fn02UGuZ8HR5l0NBynLtmuc";
 protocol="application/pgp-signature"; micalg=pgp-sha256
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 37801
Cc: Ludovic =?ISO-8859-1?Q?Court=E8s?= <ludo@HIDDEN>,
 "37801 <at> debbugs.gnu.org" <37801 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--Sig_/Fn02UGuZ8HR5l0NBynLtmuc
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi,

On Fri, 18 Oct 2019 14:02:33 +0000
Carl Dong <contact@HIDDEN> wrote:

> Perhaps Ludovic can confirm this, but I believe the reason why Guix is not
> setting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling.=
=20

Ah, that makes a lot of sense!  But the "cross-gcc" returns a cross compiler
that should know that we're cross-compiling (but it sets up SEARCH-PATHS
with CROSS_LIBRARY_PATH and CROSS_CPATH, but not NATIVE-SEARCH-PATHS.  Hmm).

But the fundamental problem remains that guix host-side can't know whether
we are cross compiling from this.  It has its own cross-compiling support
at the toplevel, at the guix command line.

The following is only tangentially related to your issue, so maybe not so
useful to you:

I've also tried

(define (xcross base-package)
  (package
    (inherit base-package)
    (search-paths '())
    (native-search-paths (list
                       (search-path-specification
                         (variable "CROSS_LIBRARY_PATH")
                         (files '("lib" "lib64")))
                       (search-path-specification
                         (variable "CROSS_CPATH")
                         (files '("lib" "lib64")))))))

and=20

    (native-inputs
     `(("pkg-config" ,pkg-config)
       ("cross-gcc" , (xcross (cross-gcc "arm-linux-gnueabihf"
                                #:xbinutils (cross-binutils "arm-linux-gnue=
abihf")
                                #:libc (xcross (cross-libc "arm-linux-gnuea=
bihf")))))))
      ;("cross-libc" ,(xcross (cross-libc "arm-linux-gnueabihf"))) ; header=
 files
       ("cross-libc-static" ,(xcross (cross-libc "arm-linux-gnueabihf")) "s=
tatic")
       ("libusb" ,libusb)))

for sunxi-tools.

But that didn't work correctly either.

What I'm trying to do is a little different from what you are trying to do.

sunxi-tools has some parts that are supposed to be run on the embedded syst=
em in
question and some that are supposed to run on the host (both are GNU system=
s).
For convenience, I'm (and upstream are) trying to provide both in the
derivation--I think because the tools can send a program via USB to the emb=
edded
system.

So if you compile sunxi-tools on x86_64, you get host tools for x86_64 and =
target
tools for ARM.

If you compile sunxi-tools on x86_64 for RISC-V, you get host tools for
RISC-V and target tools for ARM.

So it basically has to override the "which cross compiler" setting later in
the compilation process.

The more I think about it the more I'm getting the feeling that I should st=
op
trying to fit a square peg into a round hole and just add an extra package
for the target tools.

So I did the latter.
See guix-patches patch# 37823 which is now very nice.

Thanks for bringing the cross compilation topic up :)

--Sig_/Fn02UGuZ8HR5l0NBynLtmuc
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2rB1AACgkQ5xo1VCww
uqWpEQf7BYjRWTf6FxSmHJtWLtxqIQXHNcVuBMoygghLRcK+iQ+60l6deyHskjSo
N0PRD36rIRswGr5QKcjXij6j/VS0K9yTUltfAVx03UiH7/SYpEfpfKnLTQGKeVVE
JaqK7KaOiWP0xAuVrQCsO00QYlQctzBpex5T4Jc8ugCUM837byQAjjup6RZ708Ni
dWTGIGGZrgOiy8T6yvzHWse/4EUJS8jQmAdk18zWzoyIP6VXOP0IAELcgLe443OG
eaKw/hGmrj8W0mEjWOPEUHJMgNzo5tI3ESea7xUQgcITk6cKFdxDmD9S9SKrMQux
CmqmCGpa2iU3edhJ3bPcfWQM12wlQg==
=up/c
-----END PGP SIGNATURE-----

--Sig_/Fn02UGuZ8HR5l0NBynLtmuc--




Information forwarded to bug-guix@HIDDEN:
bug#37801; Package guix. Full text available.

Message received at 37801 <at> debbugs.gnu.org:


Received: (at 37801) by debbugs.gnu.org; 18 Oct 2019 14:02:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Oct 18 10:02:51 2019
Received: from localhost ([127.0.0.1]:51327 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iLSqB-0007QO-AS
	for submit <at> debbugs.gnu.org; Fri, 18 Oct 2019 10:02:51 -0400
Received: from mail4.protonmail.ch ([185.70.40.27]:22175)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <contact@HIDDEN>) id 1iLSq9-0007QB-9L
 for 37801 <at> debbugs.gnu.org; Fri, 18 Oct 2019 10:02:50 -0400
Date: Fri, 18 Oct 2019 14:02:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carldong.me;
 s=protonmail; t=1571407360;
 bh=lNZPR2egwNdsKb/3CONx+Qb86CBjTfe/Vmcvb7Aj3gY=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=JAG3eC8H6zllimxmE5ZutS8Mb+qkCQUBTlAy9MnSpd9+REYdGagacquuUeg4r/GT9
 TAnS8K8h5f4r2y1lF/0zZ1ONbmEWaoKiPjyJb2s1bjjm2D+qckTzCurU9W+kq+WmU0
 U3foyF1LCGklTjkw30zHXNXCFunwRWww348ZfNI8=
To: Danny Milosavljevic <dannym@HIDDEN>
From: Carl Dong <contact@HIDDEN>
Subject: Re: bug#37801: Possible insight into issue #30756 #include_next bug
Message-ID: <H5R52pYX-v7FYakGyXf-DjdVXYEMCTAR211IyaKX1lZ2haUGvm22ZfH8fRu1u8LWJPMCGhmUmvufVp43KseEbK69HVcAWfi0sKpuZkUEA4k=@carldong.me>
In-Reply-To: <20191018020344.78cbee48@HIDDEN>
References: <xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me>
 <20191018020344.78cbee48@HIDDEN>
Feedback-ID: a8j8tDUaJ4AYuDVBywMTwsJebN4w8TVXadJLsJb8td3t3dZi9RdXFlPaQvoFKnI9KgXySsPXcRkajVyY0cGTcA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.2 required=7.0 tests=ALL_TRUSTED,DKIM_SIGNED,
 DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF autolearn=ham
 autolearn_force=no version=3.4.2
X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mail.protonmail.ch
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 37801
Cc: =?UTF-8?Q?Ludovic_Court=C3=A8s?= <ludo@HIDDEN>,
 "37801 <at> debbugs.gnu.org" <37801 <at> debbugs.gnu.org>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Carl Dong <contact@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

Hi Danny,

Thank you so much for the links and quotes, I'm definitely going to refer b=
ack
to them in the future and you probably saved me dozens of hours :-)

> I think so. I can't figure out why Guix is not just setting up CROSS_CPAT=
H
> on its own in the first place.
> gnu/packages/cross-base.scm DOES have a search-path specification for
> CROSS_CPATH.

Perhaps Ludovic can confirm this, but I believe the reason why Guix is not
setting up CROSS_CPATH is because it doesn't _know_ it's cross-compiling. G=
uix
only sets up CROSS_CPATH when we invoke on the command line with
--target=3Dx86_64-w64-mingw32 or something like that. I'm not exactly sure =
what a
clean solution to this is, but I'd hope we can find one in the future.

I'm thinking that the reason why my final solution involved explicitly sett=
ing
the exact ordering in my CROSS_CPLUS_INCLUDE_PATH was because mingw-w64 is
considered to be libc and that makes it special somehow. Not 100% sure thou=
gh.

Cheers,
Carl Dong
contact@HIDDEN
"I fight for the users"




Information forwarded to bug-guix@HIDDEN:
bug#37801; Package guix. Full text available.

Message received at 37801 <at> debbugs.gnu.org:


Received: (at 37801) by debbugs.gnu.org; 18 Oct 2019 00:03:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 17 20:03:54 2019
Received: from localhost ([127.0.0.1]:49059 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iLFkH-0006RO-MA
	for submit <at> debbugs.gnu.org; Thu, 17 Oct 2019 20:03:53 -0400
Received: from dd26836.kasserver.com ([85.13.145.193]:42564)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <dannym@HIDDEN>) id 1iLFkF-0006RD-E4
 for 37801 <at> debbugs.gnu.org; Thu, 17 Oct 2019 20:03:52 -0400
Received: from localhost (77.117.164.54.wireless.dyn.drei.com [77.117.164.54])
 by dd26836.kasserver.com (Postfix) with ESMTPSA id 1E04A3363669;
 Fri, 18 Oct 2019 02:03:49 +0200 (CEST)
Date: Fri, 18 Oct 2019 02:03:44 +0200
From: Danny Milosavljevic <dannym@HIDDEN>
To: Carl Dong <contact@HIDDEN>
Subject: Re: bug#37801: Possible insight into issue #30756 #include_next bug
Message-ID: <20191018020344.78cbee48@HIDDEN>
In-Reply-To: <xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me>
References: <xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me>
X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-unknown-linux-gnu)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="Sig_/dObgTXQ5FfxrCz.yCQKAx7T";
 protocol="application/pgp-signature"; micalg=pgp-sha256
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 37801
Cc: ludo@HIDDEN, 37801 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

--Sig_/dObgTXQ5FfxrCz.yCQKAx7T
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hi Carl,

On Thu, 17 Oct 2019 21:56:44 +0000
Carl Dong <contact@HIDDEN> wrote:

> Note that the reason mingw-w64-x86_64-6.0.0/include is in this list at al=
l is
> because of the 'fix-env phase I added, which plucked it from CPATH and pl=
opped
> it into CROSS_CPATH.

Yeah, I did the same in sunxi-tools--which was also broken after the core-u=
pdates
merge, but had been working fine before.
It's using an x86_64->ARM cross compiler.
But just changing it to CROSS_CPATH works, there.

> 3. Does this reveal something more fundamentally wrong with how we build =
our
> search paths in the first place that should be addressed

I think so.  I can't figure out why Guix is not just setting up CROSS_CPATH
on its own in the first place.
gnu/packages/cross-base.scm DOES have a search-path specification for CROSS=
_CPATH.

Notes:

* CPATH is something like "-I", but CPATH applies after all command-line "-=
I"s.
* C_INCLUDE_PATH, CPLUS_INCLUDE_PATH and OBJC_INCLUDE_PATH are something li=
ke
"-isystem", but they apply after all command-line "-isystem"s.

Note that an empty (colon-separated) element in those environment variables
means "current working directory".

https://gcc.gnu.org/onlinedocs/gcc-6.2.0/gcc/Directory-Options.html :

>If a standard system include directory, or a directory specified with
>-isystem, is also specified with -I, the -I option is ignored. The
>directory is still searched but as a system directory at its normal
>position in the system include chain. This is to ensure that GCC's
>procedure to fix buggy system headers and the ordering for the
>include_next directive are not inadvertently changed. If you really
>need to change the search order for system directories, use the
>-nostdinc and/or -isystem options.=20

https://gcc.gnu.org/onlinedocs/cpp/Invocation.html#Invocation :

>The lookup order is as follows:
> For the quote form of the include directive, the directory of the current=
 file is searched first.
> For the quote form of the include directive, the directories specified by=
 -iquote options are searched in LTR order.
> Directories specified with -I options are scanned in left-to-right order.
> Directories specified with -isystem options are scanned in left-to-right =
order.
> Standard system directories are scanned[, except if -nostdinc[++] is spec=
ified].
> Directories specified with -idirafter options are scanned in left-to-righ=
t order.=20

--Sig_/dObgTXQ5FfxrCz.yCQKAx7T
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEds7GsXJ0tGXALbPZ5xo1VCwwuqUFAl2pAWAACgkQ5xo1VCww
uqVFYgf+KBfkOJd7YehA+OtQHDnI819hcMVMSRPLZmDyBIKVlxokjesni8/74l/c
QaaPWUpGvHNgW4BgjH3WEujT8CvOdMXUnqkeJTD30F5l1dAw1x2NNs/rcXwHC25T
V+cpwFyL/DymitEIt4JFfhGjb7SJ+sj/teUwn6mULMlC/I6SRwInIiRIMGv2AH05
4xDld8FLg1vHyh4+jTNjlIrlmd9oKEaDjqPQ9ljHNeWXbbUlJekm44ih+yMW+RVW
36XAs1xfatAnP3TdxoDoqQY4Euz3T5bvv+OnfhRGA4aYTpf5XXITjyrATTR3A6v2
MRO0bFSGBfbniZl6DzCsop9nmU8cMA==
=XI3H
-----END PGP SIGNATURE-----

--Sig_/dObgTXQ5FfxrCz.yCQKAx7T--




Information forwarded to bug-guix@HIDDEN:
bug#37801; Package guix. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 17 Oct 2019 21:57:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 17 17:57:06 2019
Received: from localhost ([127.0.0.1]:49037 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1iLDla-0003MP-1W
	for submit <at> debbugs.gnu.org; Thu, 17 Oct 2019 17:57:06 -0400
Received: from lists.gnu.org ([209.51.188.17]:57200)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <contact@HIDDEN>) id 1iLDlY-0003MI-GD
 for submit <at> debbugs.gnu.org; Thu, 17 Oct 2019 17:57:05 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:33220)
 by lists.gnu.org with esmtp (Exim 4.90_1)
 (envelope-from <contact@HIDDEN>) id 1iLDlU-0000cC-8n
 for bug-guix@HIDDEN; Thu, 17 Oct 2019 17:57:03 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.1 required=5.0 tests=BAYES_50,RCVD_IN_DNSWL_LOW,
 URIBL_BLOCKED autolearn=disabled version=3.3.2
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <contact@HIDDEN>) id 1iLDlR-00038Z-Kp
 for bug-guix@HIDDEN; Thu, 17 Oct 2019 17:56:59 -0400
Received: from mail4.protonmail.ch ([185.70.40.27]:19652)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <contact@HIDDEN>) id 1iLDlQ-00035j-Vi
 for bug-guix@HIDDEN; Thu, 17 Oct 2019 17:56:57 -0400
Date: Thu, 17 Oct 2019 21:56:44 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=carldong.me;
 s=protonmail; t=1571349408;
 bh=HsUqJk7iVa0gdxFLPeGWDlhtGn86XBS5mPfL4j1sYm0=;
 h=Date:To:From:Cc:Reply-To:Subject:Feedback-ID:From;
 b=EwrbRAuG98QkCUFw8Qw59UjjsPBL9+sZY49qlsDfkJ8VsFkp10xFRvLrYXk6iCXqc
 prcwPQyXjmmFrGr1LtTn2tNAf5rGcrJiOSJK/EeHC76kAXTn/Ha0QTHw4rkNLjt9sw
 L9WwBo8t3G6OL/7me7395Lsg46XXbGDAS8Sg+GmU=
To: "bug-guix@HIDDEN" <bug-guix@HIDDEN>
From: Carl Dong <contact@HIDDEN>
Subject: Possible insight into issue #30756 #include_next bug
Message-ID: <xvTREYeVjwuadLzEDhqSwFNXRPLuxR08Q98lclES3tkQH13Drwv9EzhWNkXbR3XZN-Tc7KCLed7yhdThX8y09kfvqRorSSayyCrW8LkSoyc=@carldong.me>
Feedback-ID: a8j8tDUaJ4AYuDVBywMTwsJebN4w8TVXadJLsJb8td3t3dZi9RdXFlPaQvoFKnI9KgXySsPXcRkajVyY0cGTcA==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
 [fuzzy]
X-Received-From: 185.70.40.27
X-Spam-Score: -1.3 (-)
X-Debbugs-Envelope-To: submit
Cc: Marius Bakke <mbakke@HIDDEN>, Jan Nieuwenhuizen <janneke@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Reply-To: Carl Dong <contact@HIDDEN>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hi all!

TLDR if you just want to know what's the final patch that worked, grep for
"final patch which works is the following"

This is a long email, but it is only long because I want to be very clear a=
nd I
include a lot of snippets of code and logs.

I originally wrote my NSIS package (introduced in e214a22007) on top of
7150743522, which was before the GREAT CORE-UPDATES MERGE. However, after
rebasing it over the GREAT CORE-UPDATES MERGE, the package stopped working.=
 My
investigations into this failure has revealed some insights which might be
useful for other cross-compiling packages and for resolving the long-standi=
ng
"important" issue #30756.

For some context, the NSIS package is somewhat special. It requires that bo=
th
native compilers and mingw-w64 cross-compilers be available, as NSIS is a
program used to create installers meant to be run on Windows.

My original method of achieving this in pre-GREAT CORE-UPDATES MERGE Guix c=
an be
see in e214a22007, whereby I added a 'fix-env phase. In that 'fix-env phase=
, I
would remove mingw-w64 paths from CPLUS_INCLUDE_PATH, C_INCLUDE_PATH, and
LIBRARY_PATH, and put them in CROSS_CPLUS_INCLUDE_PATH, CROSS_C_INCLUDE_PAT=
H,
and CROSS_LIBRARY_PATH respectively. This way, the native compilers won't t=
hink
that the mingw-w64 paths were something they were supposed to use and get
confused.

As part of the GREAT CORE-UPDATES MERGE, it would seem that CPLUS_INCLUDE_P=
ATH
and C_INCLUDE_PATH are no longer set in the build environment. Rather, only
CPATH is set.

Now, you would think that the solution here is just to replace
CPLUS_INCLUDE_PATH and C_INCLUDE_PATH in my 'fix-env phase with CPATH like =
so:

diff --git a/gnu/packages/installers.scm b/gnu/packages/installers.scm
index c987254d61..9d29e32485 100644
--- a/gnu/packages/installers.scm
+++ b/gnu/packages/installers.scm
@@ -92,7 +92,7 @@
                              ;; CROSS_-prefixed version of env vars
                              (setenv (string-append "CROSS_" env-name)
                                      (filter-delimited-string env-val ming=
w-path?))))
-                         '("CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_=
PATH"))))
+                         '("LIBRARY_PATH" "CPATH"))))
                     (add-before 'build 'fix-target-detection
                       (lambda _
                         ;; NSIS target detection is screwed up, manually


However, that does not work. Trying to build this fix results in the curiou=
s
error that we encounter in the long-standing "important" issue #30756 (to b=
e
clear, this is an error while in the `build' phase of the nsis-x86_64 packa=
ge,
not mingw-w64):

In file included from /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross=
-x86_64-w64-mingw32-7.4.0/include/c++/bits/stl_algo.h:59:0,
                 from /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross=
-x86_64-w64-mingw32-7.4.0/include/c++/algorithm:62,
                 from Contrib/InstallOptions/InstallerOptions.cpp:23:
/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.=
4.0/include/c++/cstdlib:75:15: fatal error: stdlib.h: No such file or direc=
tory
 #include_next <stdlib.h>
               ^~~~~~~~~~
compilation terminated.

For some context, here is the full environment-variables file for that fail=
ed
build:

export CPATH=3D"/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_6=
4-w64-mingw32-7.4.0/include:/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zli=
b-1.2.11/include:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/in=
clude:/gnu/store/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/include:/gnu/sto=
re/6jdshxwdrad9mlhcqc9k0g24yw45rqf1-file-5.33/include:/gnu/store/2z9hsww76a=
ag37p40671l9niq5pvvasx-gawk-5.0.1/include:/gnu/store/b5vpfzkr59bpgcsg1k9vva=
d9h5rwvpgk-make-4.2.1/include:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-b=
inutils-2.32/include:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/=
include:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/include:/gnu=
/store/7czrqpi0kwazras6pgyx0bhdn89pg0jl-linux-libre-headers-4.19.56/include=
"
export CROSS_CPATH=3D"/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64=
-x86_64-6.0.0/include"
export CROSS_LIBRARY_PATH=3D"/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mi=
ngw-w64-x86_64-6.0.0/lib"
export GUIX_LD_WRAPPER_ALLOW_IMPURITIES=3D"no"
export GUIX_LOCPATH=3D"/gnu/store/mmqp1xqffn6qw6v88i627c2bpbq36fcy-glibc-ut=
f8-locales-2.29/lib/locale"
export HOME=3D"/homeless-shelter"
export LC_ALL=3D"en_US.utf8"
export LIBRARY_PATH=3D"/gnu/store/xiiafbq3c78kxkgv5zr54zpb8r4jz5ii-scons-py=
thon2-3.0.4/lib:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_6=
4-w64-mingw32-7.4.0/lib:/gnu/store/qx7p7hiq90mi7r78hcr9cyskccy2j4bg-zlib-1.=
2.11/lib:/gnu/store/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/lib:/gnu/s=
tore/lbip9isk25isymvnb159l115xnacb5j8-xz-5.2.4/lib:/gnu/store/6jdshxwdrad9m=
lhcqc9k0g24yw45rqf1-file-5.33/lib:/gnu/store/2z9hsww76aag37p40671l9niq5pvva=
sx-gawk-5.0.1/lib:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binutils-2.32=
/lib:/gnu/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/lib:/gnu/store/=
qky1x5bb2jygy58bn6y95ygfsmpakf52-glibc-2.29-static/lib:/gnu/store/mmqp1xqff=
n6qw6v88i627c2bpbq36fcy-glibc-utf8-locales-2.29/lib"
export NIX_BUILD_CORES=3D"0"
export NIX_BUILD_TOP=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0"
export NIX_STORE=3D"/gnu/store"
export OLDPWD
export PATH=3D"/gnu/store/xiiafbq3c78kxkgv5zr54zpb8r4jz5ii-scons-python2-3.=
0.4/bin:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mi=
ngw32-7.4.0/bin:/gnu/store/9nspnmi8prly39p3xx4plvbk9dywhf4y-binutils-cross-=
x86_64-w64-mingw32-2.32/bin:/gnu/store/cnqpra8vr2l5fz00rr4yj4bp3hr00cfw-tar=
-1.32/bin:/gnu/store/py3k9zla9fj3z7430v4crqj5pyrsd3qj-gzip-1.10/bin:/gnu/st=
ore/l86azr7r3p5631wj3kk329jl1y1mpjgy-bzip2-1.0.6/bin:/gnu/store/lbip9isk25i=
symvnb159l115xnacb5j8-xz-5.2.4/bin:/gnu/store/6jdshxwdrad9mlhcqc9k0g24yw45r=
qf1-file-5.33/bin:/gnu/store/58sq8iabw3jkv0fvf95hd7sq2g4xcsnz-diffutils-3.7=
/bin:/gnu/store/v76scv4n63ip08g119rczh2mrw31zwpd-patch-2.7.6/bin:/gnu/store=
/g9d3wv1d68iflx57yp3mcp3k3sv8spsl-findutils-4.6.0/bin:/gnu/store/2z9hsww76a=
ag37p40671l9niq5pvvasx-gawk-5.0.1/bin:/gnu/store/afmvfw1yhfal48n1kjq6bk6kcw=
8sc3db-sed-4.7/bin:/gnu/store/7iyvxhp2g3v3655zqwr6biz2h0lqv7pr-grep-3.3/bin=
:/gnu/store/9kzrrccpzl6i1sfwb0drb00gi2gwk0x0-coreutils-8.31/bin:/gnu/store/=
b5vpfzkr59bpgcsg1k9vvad9h5rwvpgk-make-4.2.1/bin:/gnu/store/29jhbbg1hf557x8j=
53f9sxd9imlmf02a-bash-minimal-5.0.7/bin:/gnu/store/nc5vlidpxbvngalng30nif8n=
b3j7gfy2-ld-wrapper-0/bin:/gnu/store/3hkdiscs4910r75njbrql10znxxn7chk-binut=
ils-2.32/bin:/gnu/store/x3jx25cd3q363mr7nbgzrhrv1vza6cf7-gcc-7.4.0/bin:/gnu=
/store/ahqgl4h89xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/bin:/gnu/store/ahqgl4h89=
xqj695lgqvsaf6zh2nhy4pj-glibc-2.29/sbin"
export PWD=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0/nsis-3.04-src"
export SHLVL=3D"1"
export SOURCE_DATE_EPOCH=3D"1"
export TEMP=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0"
export TEMPDIR=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0"
export TMP=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0"
export TMPDIR=3D"/tmp/guix-build-nsis-x86_64-3.04.drv-0"
export out=3D"/gnu/store/wnjkbggyv1jgc2ld9yrissdsjqjvnim8-nsis-x86_64-3.04"

So, to get a better understanding of what was going on, I went into the
environment, and ran:

$ x86_64-w64-mingw32-g++ -E -v -xc++ - < /dev/null > /dev/null

Which yielded:

Using built-in specs.
COLLECT_GCC=3Dx86_64-w64-mingw32-g++
Target: x86_64-w64-mingw32
Configured with:
Thread model: win32
gcc version 7.4.0 (GCC)
COLLECT_GCC_OPTIONS=3D'-E' '-v' '-shared-libgcc' '-mtune=3Dgeneric' '-march=
=3Dx86-64'
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/libexec/gcc/x86_64-w64-mingw32/7.4.0/cc1plus -E -quiet -v -U_REENTRANT=
 - -mtune=3Dgeneric -march=3Dx86-64
ignoring nonexistent directory "/no-gcc-local-prefix/include"
ignoring nonexistent directory "/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj=
-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/../../=
../../x86_64-w64-mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/x86_64-w64-mingw32
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/backward
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include
 /gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed
End of search list.
COMPILER_PATH=3D/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_6=
4-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjq=
b268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/libexec/gcc/x=
86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cr=
oss-x86_64-w64-mingw32-7.4.0/libexec/gcc/x86_64-w64-mingw32/:/gnu/store/4ah=
rjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x8=
6_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cro=
ss-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/
CROSS_LIBRARY_PATH=3D/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-=
x86_64-6.0.0/lib/:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86=
_64-w64-mingw32-7.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/:/gnu/store/4ahrjqb2=
68ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.4.0/lib/gcc/x86_64-=
w64-mingw32/7.4.0/../../../../x86_64-w64-mingw32/lib/
COLLECT_GCC_OPTIONS=3D'-E' '-v' '-shared-libgcc' '-mtune=3Dgeneric' '-march=
=3Dx86-64'

So if we were to look back at the error from before, it seems that
gcc-cross-x86_64-w64-mingw32-7.4.0/include/c++/cstdlib.h was trying to incl=
ude
the file stdlib.h in directories listed AFTER it in the list of search path=
s,
BUT stdlib.h actually resides in mingw-w64-x86_64-6.0.0/include, which is b=
efore
it in the effective list of search paths.

Note that the reason mingw-w64-x86_64-6.0.0/include is in this list at all =
is
because of the 'fix-env phase I added, which plucked it from CPATH and plop=
ped
it into CROSS_CPATH.

I also took a look at Ubuntu's x86_64-w64-mingw32-g++ to see how they do it=
, and
it would seem that mingw-w64-x86_64-6.0.0/include should be the last thing =
on
that list:

ignoring nonexistent directory "/usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/.=
./../../../x86_64-w64-mingw32/sys-include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/x86_64-w64-mingw32
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include/c++/backward
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/include-fixed
 /usr/lib/gcc/x86_64-w64-mingw32/7.3-win32/../../../../x86_64-w64-mingw32/i=
nclude
End of search list.

So now we know what to fix, but how? My naive first thought was to list all=
 of
the search paths in the order I wanted them in CROSS_CPATH, like so (preten=
d the
newlines didn't exist):

CROSS_CPATH=3D
/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.=
4.0/include/c++
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/x86_64-w64-mingw32
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/backward
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed
:/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include

However, that doesn't work, what DID work was instead listing the order in
CROSS_CPLUS_INCLUDE_PATH and leaving CROSS_CPATH alone, resulting in someth=
ing
like:

CROSS_CPLUS_INCLUDE_PATH=3D
/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7.=
4.0/include/c++
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/x86_64-w64-mingw32
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/include/c++/backward
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include
:/gnu/store/4ahrjqb268ip0j0ic0l1phmixic8zfzj-gcc-cross-x86_64-w64-mingw32-7=
.4.0/lib/gcc/x86_64-w64-mingw32/7.4.0/include-fixed
:/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-6.0.0/include
CROSS_CPATH=3D/gnu/store/rabx878fijwgg0yl2bfsx0wvw7d7isnj-mingw-w64-x86_64-=
6.0.0/include

Note that I did try unsetting CROSS_CPATH, which did not work either.
Ultimately, this means that the final patch which works is the following:

diff --git a/gnu/packages/installers.scm b/gnu/packages/installers.scm
index c987254d61..794e9a758f 100644
--- a/gnu/packages/installers.scm
+++ b/gnu/packages/installers.scm
@@ -92,7 +92,20 @@
                              ;; CROSS_-prefixed version of env vars
                              (setenv (string-append "CROSS_" env-name)
                                      (filter-delimited-string env-val ming=
w-path?))))
-                         '("CPLUS_INCLUDE_PATH" "LIBRARY_PATH" "C_INCLUDE_=
PATH"))))
+                         '("CPATH" "LIBRARY_PATH"))
+                        (setenv "CROSS_CPLUS_INCLUDE_PATH"
+                                (string-append
+                                 (string-join
+                                  (map
+                                   (lambda (x) (string-append (assoc-ref %=
build-inputs "xgcc") x))
+                                       `("/include/c++"
+                                         ,(string-append "/include/c++" "/=
" ,triplet)
+                                         "/include/c++/backward"
+                                         "/lib/gcc/x86_64-w64-mingw32/7.4.=
0/include"
+                                         "/lib/gcc/x86_64-w64-mingw32/7.4.=
0/include-fixed"))
+                                  ":")
+                                 ":"
+                                 (getenv "CROSS_CPATH")))))
                     (add-before 'build 'fix-target-detection
                       (lambda _
                         ;; NSIS target detection is screwed up, manually

I'd like some feedback on

1. Whether this hack is sane or not
2. Does this apply to other packages suffering from the long-standing
"important" issue #30756
3. Does this reveal something more fundamentally wrong with how we build ou=
r
search paths in the first place that should be addressed
4. How I might improve the readability of my final patch

Cheers,
Carl Dong
contact@HIDDEN
"I fight for the users"




Acknowledgement sent to Carl Dong <contact@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guix@HIDDEN. Full text available.
Report forwarded to bug-guix@HIDDEN:
bug#37801; Package guix. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

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