Re: MinGW compilation on Windows and proposed improvements

On Tue, Feb 25, 2014 at 10:26 AM, Anoq of the Sun
<[email protected]> wrote:
> Matthew Fluet wrote:
>> Another user identified the issue:
>>   https://github.com/MLton/mlton/issues/40
>> Looks like a simple fix, but I didn't have access to a Windows/MinGW
>> machine to check.
>
> I tried this and indeed, just adding the #define MLTON_UTIL line
> made everything compile just fine.
>
> I have tried installing the built binaries, as I typically do
> on Linux, i.e.: make install, then go to the install directory
> and sudo copy -R usr/* /usr/
> but it complains about missing files under /mingw/, so
> I tried copying to /mingw/ in addition to /usr/ but it still
> complained that it is not able to run MLton and that a
> lib variable must be set. It seems that the installation
> for MinGW is thus different and I haven't found any
> description of this. Any hints? :-)

Sorry, I don't know the magic for installing the MinGW build.  Wesley
did most of the work on the MinGW port, and I know that there is a
bunch of supporting stuff in <src>/package/mingw.  Indeed, it looks
like there is a Makefile there that builds an installer.

>> I've never heard of this issue.  'run.x86-linux' is the name of the
>> actual SML/NJ executable; if you need to kill such a process, then it
>> looks like you are attempting to bootstrap MLton via SML/NJ.  This
>> isn't recommended.  Also, are you certain that the call hangs forever?
>>  A SML/NJ-built MLton is quite a bit slower than a MLton-built MLton,
>> especially in the front-end (scanning, parsing, type checking), which
>> is required for the build-constants.
>
> I have SML/NJ version 110.0.7 on the machines where this
> problem occurs, so I don't know if it uses that for
> bootstrapping merely due to its presence on the system?

SML/NJ shouldn't be used to build MLton unless the 'smlnj-mlton'
target is selected.

Perhaps it is an issue with the build/bin/mlton script.  This script
is setup to use a SML/NJ-built MLton if it exists, and so invokes
SML/NJ to determine the SML/NJ heap suffix.  Perhaps on some older
distributions, the combination of the SML/NJ version and the bash
version results in "if $smlnj -h >/dev/null 2>&1; then" hanging,
possibly waiting for user-input, since it doesn't have a "< /dev/null"
stdin redirection.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].

------------------------------------------------------------------------------
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis & security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk