[Caml-list] Building MSVC ports: coreutils link conflict

[David Allsopp]

It's a while since I've last needed to build the MSVC port of OCaml, but
this issue rang some vague bells in my memory of it.

The Microsoft Linker is called link.exe which, annoyingly, is also the name
of a coreutils utility. When building OCaml (from bash, therefore), if
/usr/bin is in PATH before the Microsoft C Compiler's Bin directory, OCaml
will attempt to use the wrong link and choke.

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?


David


--
Caml-list mailing list. Subscription management and archives:
https://sympa.inria.fr/sympa/arc/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Alain Frisch]

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?

FWIW, the way we (=LexiFi) work is that our .bashrc/.bash_profile
scripts 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.

Alain

[David Allsopp]

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?
>
> FWIW, the way we (=LexiFi) work is that our .bashrc/.bash_profile scripts
> 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 doing 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 runs 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're 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 actually 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. with 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 something in coreutils it seems OK to make an exception, at least to me?


David

[1] https://github.com/dra27/opam/blob/windows/check_linker

[Alain Frisch]

On 07/17/2015 05:42 PM, David Allsopp wrote:
> would a patch to the compiler (and to flexlink)

The compiler doesn't often call "link.exe" directly. As far as I can
tell, it does it only in case of partial linking to support module
packing in native code. And ocamlmklib can create static libraries by
calling the linker directly. I'm wondering whether it would be a good
occasion to tell flexlink how to do these two operations (for all
supported toolchains), so that ocaml itself doesn't ever talk to the
linker directly anymore, but only through flexlink. This would mean
that the logic to find the correct link.exe would only be in flexlink.

Do you think it would be a good idea?

Alain

[Damien Doligez]

On 2015-07-17, at 17:42, David Allsopp wrote:

> 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 actually 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. with 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 something in coreutils it seems OK to make an exception, at least to me?

Yuck. IMO it would be better to add a configure-time option to give the absolute path to the link executable.

In the meantime, what you can do is:

- create an empty directory (for example, /usr/local/bin/ms-tools)
- put a copy of (or a symlink to) Microsoft's link.exe into it
- add it in front of your path

-- Damien

[David Allsopp]

Damien Doligez wrote:
> On 2015-07-17, at 17:42, David Allsopp wrote:
>
> > 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 actually 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. with 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 something in coreutils it seems OK to make an
> exception, at least to me?
>
> Yuck. IMO it would be better to add a configure-time option to give the
> absolute path to the link executable.

Is OCaml soon to be configured on Windows using the standard configure script (I know there's been some work on it?)? I have dealt with it similarly at configure-time in OPAM. I agree that using an absolute path to the link executable would in general be better. That said, what do you think of Alain's suggestion to offload the entire problem to FlexDLL?

> In the meantime, what you can do is:
>
> - create an empty directory (for example, /usr/local/bin/ms-tools)
> - put a copy of (or a symlink to) Microsoft's link.exe into it
> - add it in front of your path

I realise how to solve it!! My point was trying to simplify the myriad instructions for compiling and using a Windows port of OCaml. "symlink to" also needs many more instructions if it's going to work!


David