Re: MinGW compilation on Windows and proposed improvements

Matthew Fluet wrote:
> 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 can see that this is only in the repository, not the
source distribution, but I could just grab that and copy
the package directory into the source tree and I have
tried making that work. The following is my current status.

Firstly, part of the Makefile tries to grab certain
binaries from the URL's that are in the *.url
files under package/mingw/dl/. All of these links
are broken and point to locations under
mlton.org/pages/Experimental/attachments/ (i.e. it
seems to be attachments on the Wiki pages).
I suppose that it is not a good idea to have
URLs in such a place, when a script like this
depends on it, but are those original files
still available somewhere? It seems that it
would otherwise take some work to find and
upload them all somewhere. However, I have found
and uploaded a replacement file for the one
pointed to by the URL dl/mingw32.url:
http://www.hardcoreprocessing.com/mingw/mingw-w32-1.0-bin_i686-mingw_20110812.zip

Replacing that URL seemed to work, even if
the original file was a .7z file and it is
renamed to .7z (so it must be a 7-zip feature
that it can still unpack this).

To make all this work, I recommend to first
run the MLton/MSYS installer again and
install wget and 7zip, since they are not
installed by default. Before realizing that
I could do that, I got wget to work "the hard way",
which required approximately the following in MLton/MSYS,
starting it as Administrator in Windows (hopefully
you can skip all this if you run the installer):

mingw-get update
mingw-get install msys-wget
mingw-get install msys-libintl
mingw-get install msys-libopenssl
mingw-get install msys-libiconv

This does not install that software, but rather
places the package files under
/mingw/var/cache/mingw-get/packages/
and to add to the confusion, /mingw/ is not
visible on my MLton/MSYS installation, only
on my MinGW installation that I also made, so
I had to copy the files from there and onto
a new place where I could unpack them with

lzma -d <package file>.tar.lzma
tar -xvf <package file>.tar

Most of the packages consist of several
files and in all cases, you will at
least need the bin file. For two
of the packages, likely also at least the lang
file. For libiconv, you also need the dll-2 file.

After unpacking them, I could copy the
unpacked files to /usr/ (where it would
go under /usr/bin/, /usr/etc/, /usr/lib/,
/usr/share/ and whatever). I checked that
it wouldn't overwrite any files already
on my system before doing this, but if
you had installed wget from the installer,
the relevant files would likely be there.

So, hopefully skipping the above detour and
using only the installer until now, you also
need to download Candle. I found the
file candle-0.13-beta-win.zip
online and used that. Since there were
several files unpacked here, I didn't
want to risk installing into /usr/bin/,
so instead I installed that by creating
and then copying into /usr/local/bin/
(you still need to run MLton/MSYS as
Administrator in Windows to copy this).

That was "enough" to execute make under
package/mingw/ and make it get as far
as failing due the broken URLs mentioned.

So, again, the only question here:
Are the original files from those URLs
still available somewhere?

> 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.

I tried adding the stdin redirection that you suggested,
though it had to be done in bin/mlton-script, since
that is copied to build/bin/mlton and this worked!
Very good "guess" there, thanks! :-)

I have also looked into patching the chmod, fchmod
and waitpid_nh and it seems that they are, in fact,
all implemented! Ealier I must have looked at e.g.
chown, fchown and wait or something (none of which
are implemented). However, chmod does not seem
to be implemented, nor the USR flags, e.g. S_IRUSR,
so I hope this means that they are actually in
MinGW. I haven't been able to find documentation
on that, nor test it yet (due to not yet having
successfully built the MLton/MSYS installer).

In case they are not in MinGW, then I made the
following patch (but let's see if it is needed):

Replace the relevant section in runtime/platform/mingw.h

/* ------------------------------------------------- */
/*                   Posix.FileSys                   */
/* ------------------------------------------------- */

#ifndef S_IRUSR
#define S_IRUSR _S_IREAD
#endif

#ifndef S_IRGRP
#define S_IRGRP _S_IREAD
#endif

#ifndef S_IROTH
#define S_IROTH _S_IREAD
#endif

#ifndef S_IWUSR
#define S_IWUSR _S_IWRITE
#endif

#ifndef S_IWGRP
#define S_IWGRP _S_IWRITE
#endif

#ifndef S_IWOTH
#define S_IWOTH _S_IWRITE
#endif

#ifndef S_IRWXU
#define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR)
#endif

#ifndef S_IRWXG
#define S_IRWXG (S_IRGRP | S_IWGRP | S_IXGRP)
#endif

#ifndef S_IRWXO
#define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH)
#endif

// The next five definitions are like POSIX but
// left-shifted 16 bits, to allow masking them out
// using CHMOD_S_MODE_MASK such that they have no effect
#ifndef S_ISGID
#define S_ISGID (0002000 << 16)
#endif

#ifndef S_ISUID
#define S_ISUID (0004000 << 16)
#endif

#ifndef S_IXUSR
#define S_IXUSR (0000100 << 16)
#endif

#ifndef S_IXGRP
#define S_IXGRP (0000010 << 16)
#endif

#ifndef S_IXOTH
#define S_IXOTH (0000001 << 16)
#endif



and replace the fchmod function in runtime/platform/mingw.c by

#define CHMOD_S_MODE_MASK 0xffff

int chmod (const char *fname, mode_t mode) {
         return _chmod (fname, (mode & CHMOD_S_MODE_MASK));
}

int fchmod (int filedes, mode_t mode) {
         char fname[MAX_PATH + 1];

         GetWin32FileName (filedes, fname);
         return chmod (fname, mode);
}



What I did here was to redefine some
flags in terms of others (accoring to spec),
add the *USR flags, define the flags such
that those not supported are different from
spec and explicitly masked out and finally
define chmod, and change fchmod to call chmod.

Finally, I would like to state that it is
very good work that the whole (and quite
elaborate!) process of making a MLton/MSYS
installer has been automated. Good work! (Wesley?).
Also, the MLton runtime and basis library
code is very nice and well structured.
Beautiful. Well done! :-)


Cheers,
Johnny
-- 
http://www.cex3d.net/inverse/ - 3D models from images automatically
http://www.hardcoreprocessing.com
http://www.anoq.net/music/ - creative instrumental electronic music

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