Comment author: @ygrek

Search for "program files" in ocamlbuild.exe - it has '\r' character in path (hence console output). Tracking source leads to my_std.ml String.chomp
let chomp s =
let ls = length s in
if ls = 0 then s
else if s.[ls-1] = '\n' then sub s 0 (ls - 1)
else s

Taking into account Mac OS too, maybe something like this will do :

open String

let chomp s =
let is_bad ch = match ch with | '\n' | '\r' -> true | _ -> false in
let rec cut n =
if n = 0 then 0 else if is_bad s.[n-1] then cut (n-1) else n
in
let ls = length s in
let n = cut ls in
if n = ls then s else sub s 0 n

let test s s1 = print_endline (if s1 = chomp s then "ok" else "failed")

let _ =
test "dsds" "dsds";
test "dsds\n" "dsds";
test "dsds\r" "dsds";
test "dsds\r\n" "dsds";
test "dsds\r\r\n" "dsds";
test "dsds\n\r" "dsds";
test "\r\n" "";
test "" ""

Comment author: ertai

Thanks for pointing out the bug in chomp. I've applied your change to the CVS tree, let me now if it fixes the whole problem with -where on MinGW

Comment author: @ygrek

I don't use mingw. But this issue was present on msvc build too (though it showed only as console output otherwise everything worked ok). So I grabbed cvs and built with msvc. Unfortunately the resulting ocamlbuild couldn't run because of AV in ocamlrun. It is built without symbols so I couldn't debug it.

But at least the offending string in ocamlbuild.exe doesn't contain \r character.

Comment author: @ygrek

Rebuilt with pdb and found that it picked dlls from OCAMLLIB (for 3.10) hence crash.
Now it works ok :

ocamlbuild.exe -where
D:\temp\ocaml-cvs-build\lib\ocamlbuild

Comment author: hansr

Tested against version 3.11+dev19 Private_abbrevs+natdynlink+lazy_patterns+fscanf debug (2008-10-06)

in bash:
/cygdrive/c/ocamlmgw/bin/ocamlbuild.exe -where
C:/ocamlmgw/lib/ocamlbuild

in cmd:
C:\Documents and Settings\rafhan>c:\ocamlmgw\bin\ocamlbuild.exe -where
C:\ocamlmgw\lib\ocamlbuild

(Though, it has some problems running /cygdrive/c/ocamlmgw/bin/ocamlbuild.exe
Fatal error: unknown C primitive `caml_set_parser_trace'
and similar in a CMD window which lacks mkdir and bash. Probably some error I did while building it/running it.)

So that problem seems to be fixed with that patch.

Thanks,

Hans Ole