From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id A1AAD7EEF8 for ; Fri, 17 Jul 2015 17:42:42 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of dra-news@metastack.com) identity=pra; client-ip=62.13.148.99; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of dra-news@metastack.com designates 62.13.148.99 as permitted sender) identity=mailfrom; client-ip=62.13.148.99; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="dra-news@metastack.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@outmail148099.authsmtp.net) identity=helo; client-ip=62.13.148.99; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="dra-news@metastack.com"; x-sender="postmaster@outmail148099.authsmtp.net"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DfAAA5IalVnGOUDT5bgmeBAG+ofQaUV4V3AoFHTAEBAQEBARIBAQEBAQgUCU+EIwEBAQQDNy0iAgEIGAoMAQcQMhcBDQEBBBuIJwMJ0GsBAQEHAQEBAQEBAQEWBIYehCyBAoRVOBIBgwSBFAWFYI5shG+CYIIcgjQBmQKBCYMZgXUHFyOBBAEBAQ X-IPAS-Result: A0DfAAA5IalVnGOUDT5bgmeBAG+ofQaUV4V3AoFHTAEBAQEBARIBAQEBAQgUCU+EIwEBAQQDNy0iAgEIGAoMAQcQMhcBDQEBBBuIJwMJ0GsBAQEHAQEBAQEBAQEWBIYehCyBAoRVOBIBgwSBFAWFYI5shG+CYIIcgjQBmQKBCYMZgXUHFyOBBAEBAQ X-IronPort-AV: E=Sophos;i="5.15,497,1432591200"; d="scan'208";a="140384679" Received: from outmail148099.authsmtp.net ([62.13.148.99]) by mail3-smtp-sop.national.inria.fr with ESMTP; 17 Jul 2015 17:42:41 +0200 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6HFgeGF018628 for ; Fri, 17 Jul 2015 16:42:40 +0100 (BST) Received: from romulus.metastack.com (114.212-105-213.static.virginmediabusiness.co.uk [213.105.212.114]) (authenticated bits=0) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t6HFgesl050909 for ; Fri, 17 Jul 2015 16:42:40 +0100 (BST) Received: from remus.metastack.local (remus.metastack.com [172.16.0.1]) by romulus.metastack.com (8.14.2/8.14.2) with ESMTP id t6HFgdVl013229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 17 Jul 2015 16:42:39 +0100 Received: from Remus.metastack.local ([fe80::547c:3c42:e1da:eda2]) by Remus.metastack.local ([fe80::547c:3c42:e1da:eda2%10]) with mapi id 14.03.0248.002; Fri, 17 Jul 2015 16:42:39 +0100 From: David Allsopp To: OCaml List Thread-Topic: [Caml-list] Building MSVC ports: coreutils link conflict Thread-Index: AdC+UJaHQrBjSOsmSNOQQDH9a/tTnQAmiWAAAG7R26A= Date: Fri, 17 Jul 2015 15:42:37 +0000 Message-ID: References: <003401d0be52$320d6a00$96283e00$@metastack.com> <55A646CA.8050605@lexifi.com> In-Reply-To: <55A646CA.8050605@lexifi.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [213.205.232.117] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Organization: MetaStack Solutions Ltd. X-Scanned-By: MIMEDefang 2.65 on 172.16.0.20 X-Server-Quench: 75078761-2c9a-11e5-b397-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd1ZAARAlZZVg1f DC4bFwdFRBksPQFF ChxFJgxfNlEAUAAU NkdBMnJSNkcdTBdX QSgKXEsuFQFuW2N0 bhpQaw9ZYEBKX0to UUtXQ1JXCgdpAwIA BxoBUBxtd0sCfgYG MhMhAnBeXE16fAh+ R0tTW2oDZWBob2Ye TUILflJJcQIfewIX aVl4SXMNY2AOZith QgM6YCYLEGcXGw9c RwVIKVMJXXNDNCM9 QxwDGzpnOHY7bG0r KAY6MQxUF0ELP1gu MF86EVYZNRxaAQpY EUVMCzMx X-Authentic-SMTP: 61633634383431.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 213.105.212.114/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. Subject: RE: [Caml-list] Building MSVC ports: coreutils link conflict Alain Frisch wrote: > On 07/14/2015 06:28 PM, David Allsopp wrote: > > As far as I'm aware, when started in the usual way as a login shell, > > Cygwin's bash will always prefix PATH /usr/local/bin:/usr/bin:$PATH > > ... so I was surprised to find no mention of this issue in the build > > instructions - is it simply that everyone who builds the MSVC port > > just curses at this point, alters their PATH and carries on, or is > > there an alternate, better way of setting up the build environment? >=20 > FWIW, the way we (=3DLexiFi) work is that our .bashrc/.bash_profile scrip= ts > are responsible for setting up the LIB and DIR env variables for MSVC and > prepending the correct directories in front of the PATH. (They also > define aliases to switch between the 32- and 64-bit toolchains.) We don't > rely on .bat files shipped by Microsoft. It's true that it had become > messy to support various versions of Visual Studio and of Windows SDK, but > we still prefer to know exactly how the environment is set up. It's good to know that I appear not to have missed anything obvious for doi= ng it "out of the box"! Altering /etc/profile (or whatever) was an option I= considered, but if you don't prepend /usr/bin to PATH then one quickly run= s into problems with the "alternate" versions of find and sort in %windir%\= system32 clogging up other parts of build scripts! At which point it's all = messy installation-specific changes (which I realise is fine for what you'r= e doing). Given that this conflict is only over link.exe - all the other tools in the= Microsoft toolchain are sensibly, or at least moderately uniquely, named -= would a patch to the compiler (and to flexlink) which searches the various= directories in PATH in order and identifies the first link.exe which is ac= tually a Microsoft Linker be welcomed (i.e. merged) - an ML-equivalent to [= 1], but only used if the linker has been specified given as "link" (i.e. wi= th no directory)? I'm happy to patch it, but only if it would be wanted. I = don't see a case for doing it for other commands, but with a conflict in so= mething in coreutils it seems OK to make an exception, at least to me? David [1] https://github.com/dra27/opam/blob/windows/check_linker