Open nojb opened 1 month ago
The mingw
build fails with this change, needs to be investigated.
The mingw-w64 port under Cygwin definitely needs to do this to parse x86_64-w64-mingw32-gcc -print-search-dirs
, but MSYS2 doesn't. cf. on Cygwin:
DRA@Thor ~
$ x86_64-w64-mingw32-gcc -print-search-dirs | fgrep libraries
libraries: =/usr/lib/gcc/x86_64-w64-mingw32/11/:/usr/lib/gcc/x86_64-w64-mingw32/11/../../../../x86_64-w64-mingw32/lib/x8./../x86_64-w64-mingw32/lib/../lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/x86_64-w64-mingw32/11/:/usr/x86_64-w64-mi2/11/../../../../x86_64-w64-mingw32/lib/:/usr/x86_64-w64-mingw32/sys-root/mingw/lib/
and on MSYS2:
DRA@Thor ~
$ gcc -print-search-dirs | fgrep libraries
libraries: =C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/;C:/msys64/mingw64/bin/../lib/gcc/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/lib/x86_64-w64-mingw32/14.1.0/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/lib/../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../x86_64-w64-mingw32/14.1.0/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../lib/;D:/a/msys64/mingw64/lib/x86_64-w64-mingw32/14.1.0/;D:/a/msys64/mingw64/lib/../lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../../x86_64-w64-mingw32/lib/;C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.1.0/../../../;D:/a/msys64/mingw64/lib/
I haven't checked the history, but I think that the behaviour may have been different way back in the early days when the mingw port was accessed with gcc -mno-cygwin
(and the system search dirs may have been hard-coded?), but I hadn't gone through the git history.
I think the best behaviour might be:
I think all the pieces are in place for the second part, but for now a quick fix would just be to do the first (it's obviously unequivocally wrong to be calling cygpath for MSVC).
Thanks for the quick review (on a weekend) :)
for now a quick fix would just be to do the first (it's obviously unequivocally wrong to be calling cygpath for MSVC).
OK, I did this.
I'm still dithering over whether this is the right thing to do (versus updating the documentation!). What I'm wondering is whether there are any MSVC users out there (compiling in Cygwin - i.e. using Unix-like infrastructure) where they do end up passing Cygwin-style paths (e.g. for -I
) and so where this has been quietly working?
The default value of
use_cygpath
isTry
, contrary to what the help string https://github.com/ocaml/flexdll/blob/a60821e4c2cec5142ac2437e7605473cc4254ea9/cmdline.ml#L150 says.Fixes #139