Smlnj 110 bootstrap #4
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…sting them to work under Standard ML of New Jersey v110.75 as far as the MLWorks structure, which is out-of-date with respect to the MLWORKS signature.
These changes came from or were inspired by Richard Brooksby.
This may be distribution-dependent, so further changes may be needed here.
X11 includes are in the standard include path. The - include flag isn't needed.
find . -type d -name RCS -prune -o -type f -print | xargs co -f -rMLWorks_20c1_1998_08_20
Conflicts: src/rts/GNUmakefile src/rts/runtime.rc src/rts/src/OS/NT/arch/I386/GNUmake src/rts/src/OS/Unix/license.c src/rts/src/OS/Win32/GNUmake src/rts/src/OS/Win32/mlw_ci_os.c src/rts/src/OS/Win32/win32.c src/rts/src/OS/Win32/window.c
… for fake license server link errors.
… will allow MLWorks 2.0 images to run. Verified that MLWorks 2.0 batch.img loads cleanly.
…n't seem to be defined any more, and prevented untagging of function pointers to the C stub.
…n is safe. We've observed it losing bits and crashing very quickly
…re its entry points in MLWorks integers with two-bit tags. This allows us to load and run images from MLWorks 2.0.
…ably a confusion in Hope compound naming, perhaps to appease Jo in the old days?
…s hacked 2.0 runtime can build with these makefiles.
…g environment functions to raise an exception if called. Let's hope they're not called by the batch compiler.
…t generates from the runtime system's idea of the object file version it accepts.
…emporary into waywardmonkeys-rts-compilation Conflicts: README.md -- deleted
Currently fails at the static link stage with some sort of link order problem in X libraries.
…library libXaw.a (Athena widgets).
* GNUmake (LIBRARIES, LIBRARIESSTATIC): Remove -Xp and long list of -L. Doesn't seems to be needed on Debian/Wheezy.
(I accidentally merged in the rtw-rewind branch, which createt a mess and I had to back out everything (and had to redo some work). Then when I botched it again instead of deleting .git/MERGE-HEAD I killed the commit buffer. The actual commit doesn't use any of the rts-rewind stuff but it looks weired in the git history.)
It was an defined as int but unix/__os_exit.sml actually uses word32 which caused problems with SML/NJ.
Compiling with SML/NJ exposed a number of errors like "type vars not generalized because of value restriction". According to http://www.smlnj.org/doc/Conversion/types.html, SML97 is more strict than SML90 and some rewriting was need to satify the "value restriction". I'm not familar with the code at all, so I hope that I haven't botched anything.
SML/NJ refuses to compiled lambda/_lambdaflow.sml complaing that ther is a "type definition spec inside of sharing". According to http://comp.lang.ml.narkive.com/rFKYez3I/sml-nj-error-type-definition-spec-inside-of-sharing, this may be a SML/NJ bug. I removed the sharing declaration but have no idea what problems that may cause.
There where some unsafe and apparently incorrect casts in basis/__char_array.sml and basis/__word8_array.sml that cause SML/NJ to compute bogus lengths for the arrays. Try to do get the casts right; nor sure if I was successful. In casts in basis/__byte.sml e.g. in stringToBytes still looks suspicous. Haven't touched it yet, tho.
…t generates from the runtime system's idea of the object file version it accepts. (cherry picked from commit 4aa7ca3)
Doesn't seem to be needed (at least not yet).
* nj_env.sml (MLWTime): new structure that emulates Time.time with a triple of three ints. * change_nj.sml (MLWorks.Internal.Types.time): Use MLWTime.time * change_nj.sml (MLWorks.Internal.Exit.exit): Just print a message. Needed so that we can continue to use the batch compiler. * smlnj-boot.sml: Add the commands to invoke the batch compiler for future reference.
This avoid conflicts with /usr/include/endian.h in recent Linux systems.
The i386-linux-gnu/ part is not needed on properly configured systems and it makes it easier to compile this on 64-bit systems.
dram
added a commit
to dram/mlworks
that referenced
this pull request
Sep 10, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I think I've managed to bootstrap with SML/NJ v110.74 on Debian/Wheezy.
To try it out, execute
sml make/smlnj-boot.sml.This should load the MLWorks compiler into SMLNJ and then build the .mo files.
But first a couple of symbolic links and some files in rts/gen/ must be generated. The complete sequence should look like this:
cd mlworks/srcgit checkout smlnj-110-bootstrapln -s i386/ machineln -s unix/ systemln -s ../system/_os.sml mainln -s ../system/__os.sml mainmake -C rts/ ARCH=I386 OS=Linuxsml make/smlnj-boot.smlAfter all .mo files are ready building the batch.img should work as usual:
make -C images/I386/Linux/ OS=Linux ARCH=I386 batch.imgThe guib.img can be built with:
LD_LIBRARY_PATH=rts/bin/I386/Linux/ rts/bin/I386/Linux/main-g -MLWpass xx -load images/I386/Linux/batch.img xx -pervasive-dir pervasive/ -project xinterpreter.mlp -configuration I386/Linux -target xinterpreter.sml -buildmake -C images/I386/Linux/ OS=Linux ARCH=I386 guib.imgThat can be started with:
XUSERFILESEARCHPATH=app-defaults/MLWorks-mono LD_LIBRARY_PATH=rts/bin/I386/Linux/ rts/bin/I386/Linux/main-g -MLWpass xx -load images/I386/Linux/guib.img xxThe command line option "-tty" can be used start MLWorks without the GUI environment.
The testsuite can be run with:
cd ../test_suite/CHECK_SUCCESS_ALL -src ../src -dir I386/LinuxFor me all tests except "./basis/real_arrays.sml" succeed.