Bug#624533: [mingw32-ocaml] please provide mingw-w64-ocaml
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
Reply to: