Hi, On Fri, Apr 29, 2011 at 12:20:17PM -0500, Romain Beauxis wrote: > Thank you for this very good report and for trying. I will make sure > that I take this in consideration for the next upload.
I was about to file a similar bug (as maintainer of mingw-w64 rather than a user of mingw32-ocaml) when I came across this one. I've just tried rebuilding mingw32-ocaml using gcc-mingw-w64, which is now based on gcc 4.6.1, and it still works fine. Török's instructions are correct, but can be improved slightly: the only necessary build- and runtime- dependencies are mingw-w64, which will always depend on everything necessary to get a full gcc-based toolchain targetting both 32- and 64-bit Windows. I'm hoping to get rid of gcc-mingw32 altogether, which is why I'm particularly interested in this bug! When looking at the resulting package, I also noticed a couple of oddities: * there's link from /usr/bin/flexlink to ../lib/ocaml/flexdll/flexlink.exe, which seems strange - the .exe is an ELF executable, and the /usr/bin file isn't prefixed with i686-w64-mingw32- * the package ships binaries in /usr/i686-w64-mingw32/bin (/usr/i586-mingw32msvc/bin in the current package), along with prefixed links in /usr/bin; would it be possible to only ship the prefixed files in /usr/bin? Concerning the latter point, the reason I ask is that /usr/i586-mingw32msvc and /usr/i686-w64-mingw32 aren't policy-compliant; eventually the ../include and ../lib directories will be handled by multiarch (and move to /usr/include/i686-w64-mingw32 etc.), but the ../bin directory should probably disappear. This is also supported by the autotools approach favouring prefixed tools (i686-w64-mingw32-gcc for example) rather than tools in specific directories (/usr/i686-w64-mingw32/bin/gcc). Regards, Stephen -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org