Re: MinGW compilation on Windows and proposed improvements

On Sun, Feb 23, 2014 at 6:50 AM, Anoq of the Sun
<[email protected]> wrote:
>
> I have been trying to compile MLton under MinGW/MSYS
> on Windows, using the MLton binary package from version
> 20100608.
>
> When compiling MLton20100608, there is a problem
> with latex not being present. Is it possible
> to build it without documentation or is there some
> other recommended way of making a MinGW build from source?

The 'all-no-docs' target of the top-level Makefile should build all
the binaries, while not building any of the documentation.

> The 20100608 binary release works great, but I
> intend to apply patches to the source (see below).
>
> When trying to compile MLton20130715 (still on
> MinGW/MSYS on Windows), there is
> an actual compilation error with MLton_strerror
> being undefined during link (I see in the code
> that there is something funky going on with
> undefining and redefining stderror):
>
> make -C runtime
> make[3]: Entering directory `/v/MLton/mlton-20130715/runtime'
> gcc -std=gnu99   -fno-common  -pedantic -Wall -Wextra -Wformat=2
> -Wswitch-default -Wswitch-enum -Wuninitialized -Winit-self
> -Wstrict-aliasing=2 -Wfloat-equal -Wundef -Wshadow -Wpointer-arith
> -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return
> -Wstrict-prototypes -Wold-style-definition -Wmissing-prototypes
> -Wmissing-declarations -Wmissing-field-initializers -Wmissing-noreturn
> -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -m32
> -Wno-format -Wno-missing-format-attribute -I. -Iplatform
> -Wdisabled-optimization -O2 -fomit-frame-pointer -falign-loops=2
> -falign-jumps=2 -falign-functions=5 -o gen/gen-types gen/gen-types.c util.o
> util.o:util.c:(.text+0x287): undefined reference to `MLton_strerror'
> collect2: ld returned 1 exit status

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.

> Regarding building MLton20100608 from source,
> there is occasionally (on some machines,
> typically with older Linux distributions,
> it seems?) a problem on Linux that
> this call hangs forever (then I have to kill
> e.g. a process called run.x86-linux to stop it;
> CTRL+C on the shell won't work):
>
> Creating constants file.
> "/usr/local/anoq_installed/MLton/20100608/Linux/src/patched/mlton-20100608/build/bin/mlton"
>
> -target "self" -build-constants true >tmp.c
>
> This is not a big problem for me though, since
> I can either use the binary distribution or
> upgrade the Linux distribution (if patching
> and building from source is needed).

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 would also like to propose some patches with
> improvements. There is a small can of worms
> regarding MLton.Process.{create|kill|reap}
> that I would like to sort out first.

Most of the suggestions seem reasonable.  Might be helpful to see the patch.

> Now for determining whether a process has
> actually been killed by MLton.Process.kill.
> Firstly, in general, note that the SML basis
> library seems to raise exceptions instead of using
> return codes for Posix:
> http://www.standardml.org/Basis/posix-error.html
> In MLton, I have at least experienced that
> MLton.Process.reap and Posix.Process.waitpid_nh
> may raise exceptions, but it seems that
> {Posix|MLton}.Process.kill do not.
> POSIX' kill in C seems to return -1 if a child
> process is not found (e.g. due to having been
> killed) and so does waitpid with the WNHANG
> flag (corresponding to Posix.Process.waitpid_nh).
> So one possible comment is that maybe
> {Posix|MLton}.Process.kill should raise
> exceptions in this case? Then testing whether
> a process has been killed would just be a
> matter of continuously calling kill, until
> it raises an exception.

Posix.Process.kill should raise a SysErr exception, based on the errno
value when kill returns ~1.

> In case kill is actually not supposed to
> raise an exception, then an alternative
> (and maybe better or more correct?) approach
> would be to use waitpid_nh, in which case I
> would need to be able to use it on processes
> created with MLton.Process.create.
> To be able to do that, the pid of the process
> would be needed. A very small and simple
> extension that allows this is to add the line:
>
> val getPid = fn z => make #pid z
>
> after the lines defining getStderr, getStdin and getStdout
> in the file basis-library/mlton/process.sml and add the line:
>
> val getPid:    ('stdin, 'stdout, 'stderr) t -> pid
>
> in the corresponding process.sig file.
> The type pid is compatible with Posix.Process.pid,
> as needed (if this pid type was intended to be
> opaque, it would be necessary to convert it to
> Posix.Process.pid, but that's currently not necessary).

Seems quite reasonable to be able to get the pid of a
MLton.Process.create-ed process.

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