Bug 191899 - [MAINTAINER] lang/sml-nj-devel: update to 110.76, unbreak, pkgngify, +amd64, -gmake
Summary: [MAINTAINER] lang/sml-nj-devel: update to 110.76, unbreak, pkgngify, +amd64, ...
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: Normal Affects Some People
Assignee: Johannes 5
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-07-16 15:23 UTC by Johannes 5
Modified: 2014-09-02 19:42 UTC (History)
4 users (show)

See Also:


Attachments
smlnj-devel-110.76.patch (77.16 KB, patch)
2014-07-16 15:23 UTC, Johannes 5
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Johannes 5 2014-07-16 15:23:17 UTC
Created attachment 144727 [details]
smlnj-devel-110.76.patch

- unbreak
- be compatible with pkgng (enable pkg-install to run as stdin of /bin/sh)
- stagify (by (ab)using the SML/NJ compilation manager's CM_PATHCONFIG)
- update to 110.76
- initial support for amd64 (*)
- don't depend on gmake
- merge files/plist-everything into pkg-plist
- fresh version of pkg-descr (from SML/NJ website)

(*) Yet untested on FreeBSD 10 amd64 due to lack of hardware.
Recompiling the compiler doesn't work on amd64 (i.e. it doesn't work
for me on amd64 FreeBSD 9.2-STABLE r257053), so the corresponding
OPTIONS are currently disabled for amd64.
Getting SML/NJ to build on amd64 (in 32bit mode) at all was
started by an initial patch and instructions from Brian M. Waters in
June 2013 - thanks! (The delay is my fault.)

Generated with FreeBSD Port Tools 1.02 (mode: update, diff: SVN)
Comment 1 Timothy Beyer 2014-07-17 09:07:02 UTC
I don't know if this helps, but I have gotten SML/NJ to run inside of a 32-bit jail on amd64:

1) I modified the PREFIX in multiexec-wrapper to something along the lines of /usr/jails/[name_of_jail]/usr/local

2) Next, I modified lookup_executable_result to be /usr/jails/[name_of_jail]/$result (also in multiexec-wrapper)

3) I added "*64) ARCH=x86;;" in /usr/local/smlnj/bin/.arch-n-opsys (in the case for bsd)

4) I copied the modified multiexec-wrapper to the 64-bit host as file /usr/local/bin/multiexec-wrapper

5) Made a symlink from /usr/local/bin/multiexec-wrapper to /usr/local/bin/sml

Note that step #3 needs to be repeated every time SML/NJ is reinstalled in the jail.

Probably this won't help much, since the development version is probably different, but it works with version 110.71 at least.
Comment 2 Johannes 5 2014-07-17 14:59:59 UTC
(In reply to Timothy Beyer from comment #1)
> I don't know if this helps, but I have gotten SML/NJ to run inside of
> a 32-bit jail on amd64:

Thanks for your report. But before I'll try to come up with a more
detailed response, could you consider the following questions:
- Did you take an smlnj-devel-110.71.t?z binary package created on an
  i386 machine and installed or unpacked that (in a (32-bit-)jail) on
  amd64?
- Which version(s) of FreeBSD run(s) on the amd64 machine(s) you're
  using?

> 1) I modified the PREFIX in multiexec-wrapper to something along the
> lines of /usr/jails/[name_of_jail]/usr/local

Sounds like this multiexec-wrapper is installed on the host system, and
not in the jail. But "jail" implies "chroot", and so in order to start
sml *within* the (32-bit-)jail the multiexec-wrapper itself should live
in /usr/jails/[name_of_jail]/usr/local and it's PREFIX setting inside
should be /usr/local. Then it would be able to do its job after you
jail(8) or chroot(8) to /usr/jails/[name_of_jail]. Or do I miss
something? (Maybe I don't fully understand your setup.)

> [...]
> Probably this won't help much, since the development version is
> probably different, but it works with version 110.71 at least.

It would be very helpful if you could test the patch in this PR
(apply it against the current state of ports/lang/sml-nj-devel).
That would be helpful for this PR and (more importantly:) for you,
as it should make your workaround on amd64 obsolete:-)

Using the patched version of the port I could build sml-nj-devel
directly from source on amd64, and run sml and also math/isabelle on
top of it. This requires the toolchain to understand the "-m 32"
options and the presence of /usr/lib32. Both should be fairly
standard I think ... here's the mileage from the jail on amd64 within
which I developed and tested the patch:

root@zzz:~ # uname -srm
FreeBSD 9.2-STABLE amd64
root@zzz:~ # sysctl security.jail.jailed
security.jail.jailed: 1
root@zzz:~ # pkg info -x sml
smlnj-devel-110.76
root@zzz:~ # ldd /usr/local/smlnj/bin/.run/run.x86-freebsd
/usr/local/smlnj/bin/.run/run.x86-freebsd:
	libm.so.5 => /usr/lib32/libm.so.5 (0x28081000)
	libc.so.7 => /usr/lib32/libc.so.7 (0x2809b000)

Thanx!
Johannes

ps The "-devel" in "sml-nj-devel" is mainly historic - 110.76 is
  the current "official" version from the SML/NJ project.)
Comment 3 Timothy Beyer 2014-07-17 16:30:37 UTC
(In reply to joemann from comment #2)
> (In reply to Timothy Beyer from comment #1)
> > I don't know if this helps, but I have gotten SML/NJ to run inside of
> > a 32-bit jail on amd64:
> 
> Thanks for your report. But before I'll try to come up with a more
> detailed response, could you consider the following questions:
> - Did you take an smlnj-devel-110.71.t?z binary package created on an
>   i386 machine and installed or unpacked that (in a (32-bit-)jail) on
>   amd64?
> - Which version(s) of FreeBSD run(s) on the amd64 machine(s) you're
>   using?

Basically, I installed sml-nj-devel from ports a while back on a 32-bit jail, which is 10.0 RELEASE-i386.  The Host system is 10.0 RELEASE-amd64, and I execute SMJNJ from the host.  The actual install lives on the jail, whereas I use the executable on the host, although it depends to some extent on /usr/lib32 on the host to run.

It's basically a hack I use for programs that I haven't migrated to 64-bit yet (I've used something similar for a number of ports that were stuck in 32-bit), and won't compare favorable to your more sophisticated approach, but it sometimes is useful.

> 
> > 1) I modified the PREFIX in multiexec-wrapper to something along the
> > lines of /usr/jails/[name_of_jail]/usr/local
> 
> Sounds like this multiexec-wrapper is installed on the host system, and
> not in the jail. But "jail" implies "chroot", and so in order to start
> sml *within* the (32-bit-)jail the multiexec-wrapper itself should live
> in /usr/jails/[name_of_jail]/usr/local and it's PREFIX setting inside
> should be /usr/local. Then it would be able to do its job after you
> jail(8) or chroot(8) to /usr/jails/[name_of_jail]. Or do I miss
> something? (Maybe I don't fully understand your setup.)

The multiexec-wrapper lives on both systems actually.  The only reason why I modify is it because it contains hardcoded paths, which don't actually make sense from the host side (the way I do it is sort of like some linuxulator ports.

> It would be very helpful if you could test the patch in this PR
> (apply it against the current state of ports/lang/sml-nj-devel).
> That would be helpful for this PR and (more importantly:) for you,
> as it should make your workaround on amd64 obsolete:-)

I'm very much looking forward to testing it, as my workaround just isn't the same as what you've proposed, which looks like a far more complete solution.

Further, since my workaround is very complicated, it is too hard to expect people to "just set up a 32-bit jail" for a dependency, then build math/isabelle.  It does actually work on my machine, but I'd never expect a similar scheme to actually make it in to ports.

> Using the patched version of the port I could build sml-nj-devel
> directly from source on amd64, and run sml and also math/isabelle on
> top of it. This requires the toolchain to understand the "-m 32"
> options and the presence of /usr/lib32. Both should be fairly
> standard I think ... here's the mileage from the jail on amd64 within
> which I developed and tested the patch:

This sounds great.  I'll work on the staging for math/isabelle again.
 
> root@zzz:~ # uname -srm
> FreeBSD 9.2-STABLE amd64
> root@zzz:~ # sysctl security.jail.jailed
> security.jail.jailed: 1
> root@zzz:~ # pkg info -x sml
> smlnj-devel-110.76
> root@zzz:~ # ldd /usr/local/smlnj/bin/.run/run.x86-freebsd
> /usr/local/smlnj/bin/.run/run.x86-freebsd:
> 	libm.so.5 => /usr/lib32/libm.so.5 (0x28081000)
> 	libc.so.7 => /usr/lib32/libc.so.7 (0x2809b000)

Apparently my workaround works in a similar way, implicitly using lib32 as well.

> ldd /usr/jails/i386/usr/local/smlnj/bin/.run/run.x86-freebsd
/usr/jails/i386/usr/local/smlnj/bin/.run/run.x86-freebsd:
        libm.so.5 => /usr/lib32/libm.so.5 (0x28080000)
        libc.so.7 => /usr/lib32/libc.so.7 (0x280a5000)


> Thanx!
> Johannes

Thank you! I can only imagine how much time it took to get SML-NJ properly ported to amd64, especially compared to something comparatively easier like lang/mlton.

Regards,
Tim
Comment 4 Robert Cina 2014-07-18 11:10:36 UTC
I applied the attached patch above to the current sml-nj-devel port but it failed with the following output:

./config/install.sh: Using shell /bin/sh.
./config/install.sh: SML root is /usr/ports/lang/sml-nj-devel/work.
./config/install.sh: Installation directory is /usr/ports/lang/sml-nj-devel/work.
./config/install.sh: Installing version 110.76.
./config/install.sh: URL of source archive is http://smlnj.cs.uchicago.edu/dist/working/110.76/.
./config/install.sh: Script /usr/ports/lang/sml-nj-devel/work/bin/.arch-n-opsys reports ARCH=x86; OPSYS=freebsd; HEAP_SUFFIX=x86-bsd.
/usr/ports/lang/sml-nj-devel/work/config/unpack: Un-GZIP-ing and un-TAR-ing run-time archive.
  I can't seem to find a patch in there anywhere.
./config/install.sh: !!! patch file /usr/ports/lang/sml-nj-devel/files/do-patch-base_runtime_objs_makefile.orig failed to patch.
*** Error code 1

Stop.
make[1]: stopped in /usr/ports/lang/sml-nj-devel
*** Error code 1

Stop.
make: stopped in /usr/ports/lang/sml-nj-devel



Below is my system details.  

$ uname -a

FreeBSD polyfree.my.domain 10.0-STABLE FreeBSD 10.0-STABLE #9 r268458: Wed Jul  9 12:39:50 EDT 2014     root@polyfree.my.domain:/usr/obj/usr/src/sys/GENERIC  amd64


Hope the above information helps as I am interested in having a working sml-nj-devel port.
Comment 5 Johannes 5 2014-07-18 15:33:30 UTC
(In reply to Robert Cina from comment #4)
> I applied the attached patch above to the current sml-nj-devel port
> but it failed with the following output:
> [...]
> ./config/install.sh: !!! patch file /usr/ports/lang/sml-nj-devel/files/do-patch-base_runtime_objs_makefile.orig failed to patch.
> *** Error code 1

Can you see an empty file do-patch-base_runtime_objs_makefile.orig in
the files subdirectory of the port? If so, then you applied the patch
manually but did not remove the remaining junk like old (*.orig)
versions. You could run something like

	find . \( -name '*.orig' -o -size 0c \) -print -delete

in the sml-nj-devel directory before starting the build.
Another option is to check out and patch the port using svn:

	svnlite co svn://svn.FreeBSD.org/ports/head/lang/sml-nj-devel sml-nj-devel.svn
	# A    sml-nj-devel.svn/pkg-plist
	# A    sml-nj-devel.svn/Makefile
	# [...]
	cd sml-nj-devel.svn
	fetch -o smlnj-devel-110.76.patch -q --no-verify-peer 'https://bugs.freebsd.org/bugzilla/attachment.cgi?id=144727'
	md5 smlnj-devel-110.76.patch
	# MD5 (smlnj-devel-110.76.patch) = 048e1ed9c49ef6ed9e33244a82752221
	svnlite patch smlnj-devel-110.76.patch
	# U         Makefile
	# U         distinfo
	# A         files/do-patch-base_runtime_objs_makefile
	# [...]

This way you won't need the above `find ... -delete` because svn
automagically does the right thing.

> Below is my system details.  
> $ uname -a
> FreeBSD polyfree.my.domain 10.0-STABLE FreeBSD 10.0-STABLE #9 r268458: Wed Jul  9 12:39:50 EDT 2014 root@polyfree.my.domain:/usr/obj/usr/src/sys/GENERIC  amd64

Great, that's exactly the configuration (FreeBSD 10 amd64) which I
can't test myself.

> Hope the above information helps as I am interested in having a
> working sml-nj-devel port.

And I'm very interested in getting to know what happens to your build
after you remove *.orig:-)

Cheers
Johannes
Comment 6 Robert Cina 2014-07-18 16:08:00 UTC
Thanks for the patch and the great instructions to solve my issues with patching.  I still have lots to learn.  The port compiled and installed smlnj 110.76 on my system. Typing sml at the command prompt starts the SML interpreter.  

This is the result on my system:

rob@polyfree:~ %  uname -srm
FreeBSD 10.0-STABLE amd64
rob@polyfree:~ %  pkg info -x sml
smlnj-devel-110.76
rob@polyfree:~ %  ldd /usr/local/smlnj/bin/.run/run.x86-freebsd
/usr/local/smlnj/bin/.run/run.x86-freebsd:
	libm.so.5 => /usr/lib32/libm.so.5 (0x28081000)
	libc.so.7 => /usr/lib32/libc.so.7 (0x280a6000)
rob@polyfree:~ %  sml
Standard ML of New Jersey v110.76 [built: Fri Jul 18 11:52:22 2014]
- 

Thanks again for your hard work!
Comment 7 Johannes 5 2014-07-18 17:44:49 UTC
(In reply to Robert Cina from comment #6)
> [...] The port compiled and installed smlnj 110.76 on my system.
> Typing sml at the command prompt starts the SML interpreter.  
> This is the result on my system:
> 
> rob@polyfree:~ %  uname -srm
> FreeBSD 10.0-STABLE amd64
> rob@polyfree:~ %  pkg info -x sml
> smlnj-devel-110.76
> rob@polyfree:~ %  ldd /usr/local/smlnj/bin/.run/run.x86-freebsd
> /usr/local/smlnj/bin/.run/run.x86-freebsd:
> 	libm.so.5 => /usr/lib32/libm.so.5 (0x28081000)
> 	libc.so.7 => /usr/lib32/libc.so.7 (0x280a6000)
> rob@polyfree:~ %  sml
> Standard ML of New Jersey v110.76 [built: Fri Jul 18 11:52:22 2014]
> - 

2+3;
val it = 5 : int
:-)

Great! Thanks for testing. To me your result suggests that it's time to
pray for a ports committer who will take (the burden of:) this PR.

> Thanks again for your hard work!

:-) Although this port occasionally seems to require quite a lot of
time and diving-in-the-mud, this work is nothing compared to the work
that was put into SML/NJ itself. I'd really love to have the time to
use and explore it myself (e.g. FLINT).

Let's pray ... ;-)
Johannes
Comment 8 John Marino freebsd_committer 2014-07-22 18:11:36 UTC
sml-nj has just been marked BROKEN.

Is is feasible to update sml-nj to what this PR says sml-nj-devel should be?  And then remove sml-nj-devel because really, why do we need two ports?
Comment 9 Kurt Jaeger freebsd_committer 2014-07-22 19:17:44 UTC
I'll take it. The test on 10amd64 went fine. Would the maintainer approve the
deletion of sml-nj-devel and making this the lang/sml-nj port ?
Comment 10 Johannes 5 2014-07-29 19:54:21 UTC
(In reply to Robert Cina from comment #6)
> [...]
> This is the result on my system:
> [...]
> rob@polyfree:~ %  sml
> Standard ML of New Jersey v110.76 [built: Fri Jul 18 11:52:22 2014]
> - 

I've been so happy because of your result that I forgot to mention how
to (quickly) test sml:

1. Do a "make clean" in the port's directory or at least move the
   WRKDIR (which also includes the STAGEDIR) away, e.g.:
   mv `make -V WRKDIR` `make -V WRKDIR`.bak

2. echo "2+3; open List;" | sml

This way autoloading of SML/NJ libraries (.cm) is tested as well.
When you get something like ...

- val it = 5 : int
[autoloading]
unexpected exception (bug?) in SML/NJ: Io [Io: openIn failed on "/wrkdirs/usr/ports/sml-nj-devel/work/base/system/sml.boot.x86-unix/smlnj/basis/.cm/x86-unix/basis.cm", No such file or directory]
  raised at: Basis/Implementation/IO/bin-io-fn.sml:617.25-617.71
             ../cm/util/safeio.sml:30.11
             ../compiler/TopLevel/interact/evalloop.sml:44.55

... then you know that autoloading is broken, so the port is buggy.
It won't work for users or for dependent ports although packaging is
OK, and sml runs, and correctly calculates holy Discordian numbers:-)

I mention the "open List" test because the autoloading problem was
preventing the port from being staged. While this is solved by the
patch attached to this PR, it might return some (unholy;) day ...

Cheers
Johannes
Comment 11 Johannes 5 2014-07-29 20:02:13 UTC
(In reply to John Marino from comment #8)
> sml-nj has just been marked BROKEN.

Unfortunately it's already marked DEPRECATED, because the build broke
last year;-( (I guess because the build cluster is trying to build it
on machines with amd64 processors.)

> Is is feasible to update sml-nj to what this PR says sml-nj-devel
> should be? And then remove sml-nj-devel because really, why do we
> need two ports?

I think you're right. We don't need both, because
- 110.0.7 is no longer advertised on the SML/NJ website,
- which now calls the working versions (like 110.76) releases,
- and there are no (longer any) ports depending on 110.0.7.

So I approve your suggestion - with one small modification:

The port's directory name in the ports tree should become the same as
the PORTNAME, i.e. just "lang/smlnj" without the "-".

To my knowledge, the "-" is purely historic and has created some
confusion (at least in the past).

Thanx for your suggestion, particularly as it prevents me from trying
to stagify 110.0.7:-)
Johannes
Comment 12 Kurt Jaeger freebsd_committer 2014-07-29 20:04:57 UTC
I tested 

echo "2+3; open List;" | sml

on 10.0-amd64, worked fine.

As you wrote, I'll commit it as lang/smlnj and we'll delete sml-nj-devel.

It will me one day or so to commit it.
Comment 13 Johannes 5 2014-07-29 20:07:26 UTC
(In reply to Kurt Jaeger from comment #9)
> I'll take it.

Great. (And (as usual:( sorry for my delay.)

> The test on 10amd64 went fine. Would the maintainer approve the
> deletion of sml-nj-devel and making this the lang/sml-nj port ?

As said in my reply to John: yes.

And (while you're about to touch this historic mess;) I'd like to ask
you to also consider my suggestion to remove the "-" in the "sml-nj" of
the directory name of the port. If you agree, you might want to use a
slight modification of this PR's patch [1], which I have prepared for
this case ("lang/sml-nj-devel" -> "lang/smlnj").

Thanx!
Johannes

[1] <ftp://offshore.free.de/pub/patch/sml-nj-devel.patch.20140728>
MD5 (sml-nj-devel.patch.20140728) = 732c31530909cc8f337990622ce03025
If you think it's useful, let me know if I should attach it to the PR.
Comment 14 commit-hook freebsd_committer 2014-07-30 19:43:23 UTC
A commit references this bug:

Author: pi
Date: Wed Jul 30 19:42:53 UTC 2014
New revision: 363509
URL: http://svnweb.freebsd.org/changeset/ports/363509

Log:
  lang/smlnj: 110.71 -> 110.76

  - unbreak and support staging
  - support amd64
  - no longer depends on gmake
  - moves lang/sml-nj-devel to lang/smlnj
  - supersedes lang/sml-nj

  PR:             191899
  Reviewed by:	Robert Cina <transitive@gmail.com>,
  		Timothy Beyer <beyert@cs.ucr.edu>
  Approved by:	Johannes <joemann@beefree.free.de> (maintainer)

Changes:
  head/MOVED
  head/lang/Makefile
  head/lang/sml-nj/
  head/lang/sml-nj-devel/
  head/lang/smlnj/
  head/lang/smlnj/Makefile
  head/lang/smlnj/distinfo
  head/lang/smlnj/files/do-patch-base_runtime_objs_makefile
  head/lang/smlnj/files/do-patch-base_runtime_objs_mk.x86-freebsd
  head/lang/smlnj/files/extra-patch-base_runtime_c-libs_smlnj-math_ctlrndmode.c
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-8-i386-__types.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-8-i386-endian.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-8-i386-ieeefp.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-8-i386-signal.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-9-i386-__types.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_freebsd-9-i386-endian.h
  head/lang/smlnj/files/extra-patch-base_runtime_include_ml-unixdep.h
  head/lang/smlnj/files/patch-config___arch-n-opsys
  head/lang/smlnj/files/patch-config___heap2exec
  head/lang/smlnj/files/patch-config_install.sh
  head/lang/smlnj/files/pkg-install.in
  head/lang/smlnj/files/plist-everything
  head/lang/smlnj/pkg-descr
  head/lang/smlnj/pkg-plist
Comment 15 Kurt Jaeger freebsd_committer 2014-07-30 19:44:41 UTC
Committed, thanks all for the hard work. Now, please go and test
and tell me where I failed 8-)
Comment 16 Kurt Jaeger freebsd_committer 2014-07-30 19:46:10 UTC
Ah, and one more thing for the maintainer to look after or ask upstream:

Can you check why this pops up ? Is tmpnam really needed ?

/usr/local/smlnj/bin/.run/run.x86-freebsd (USES POSSIBLY INSECURE FUNCTIONS: tmp
nam)
/usr/local/smlnj/bin/.run/run.x86-freebsd.so (USES POSSIBLY INSECURE FUNCTIONS:
tmpnam)
Comment 17 Johannes 5 2014-08-01 17:42:22 UTC
(In reply to Kurt Jaeger from comment #16)
> Ah, and one more thing for the maintainer to look after or ask upstream:
> Can you check why this pops up ? Is tmpnam really needed ?
> 
> /usr/local/smlnj/bin/.run/run.x86-freebsd (USES POSSIBLY INSECURE FUNCTIONS: tmpnam)
> /usr/local/smlnj/bin/.run/run.x86-freebsd.so (USES POSSIBLY INSECURE FUNCTIONS: tmpnam)

Thanks for explicitly pointing at this. I had looked at the tmpnam(3)
issue years ago, but could not see an immediate solution. The
replacement mkstemp(3), which is recommended by the tmpnam man page,
has a different type than tmpnam. So it does not work as a drop in
replacement and I (unfortunately) got used to the "POSSIBLY INSECURE"
warning.

But now you can read the long story (the reason why this should be
handled by upstream as well) below, and you might want to review my
suggestion to resolve this issue (formatted as a small patch against
(the shiny new:) lang/smlnj):

<ftp://offshore.free.de/pub/patch/smlnj.patch.20140801>
MD5 (smlnj.patch.20140801) = 5485c00c6faa2a04c6a1cbf33df3632e
(Let me know, if I should attach it here or in fresh PR or ...)

Here are the results of my quick tests of that patch:

1. /tmp is writable by the user:

% echo "2+3; OS.FileSys.tmpName ();" | sml
Standard ML of New Jersey v110.76 [built: Fri Aug  1 17:48:02 2014]
- val it = 5 : int
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
val it = "/tmp/TMP-SMLNJ.OmYMdn" : string
% ls -l /tmp/TMP-SMLNJ.OmYMdn
-rw-------  1 me  mygroup  0 Aug  1 18:24 /tmp/TMP-SMLNJ.OmYMdn

2. /tmp mounted read-only:

% echo "2+3; OS.FileSys.tmpName ();" | sml
Standard ML of New Jersey v110.76 [built: Fri Aug  1 17:48:02 2014]
- val it = 5 : int
[autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
uncaught exception SysErr [SysErr: Read-only file system [rofs]]
  raised at: <tmpname.c>

Would be cool if someone could try the patch, and verify that it works
for him or her as "advertised" above (and that the "POSSIBLY INSECURE"
warning is gone after applying the patch:-).

As this is a modification of the runtime, I'd rather do some more
testing before I'll suggest to commit it to the FreeBSD ports and/or
send it to upstream. If someone finds a call site (other than
nlffi/gen/main.sml;) for the Basis library function OS.FileSys.tmpName
within any SML sources he or she is using, please let me know.

Thanks!
Johannes


ps Here comes the story of OS.FileSys.tmpName (just for the records;):

The changelog of the Basis library specification [1] says ...

 July 14, 2003
 Fixed the semantics of OS.FileSys.tmpName to avoid a race condition.

... which is in line with the security considerations in the man page
of tmpnam(3). And the (corrected) specification of tmpName [2] is
approximately that of mkstemp(3):

 val tmpName : unit -> string

 This creates a new empty file with a unique name and returns the full
 pathname of the file. The named file will be readable and writable by
 the creating process, but, if the host operating systems supports it,
 not accessible by other users. This function can be used to create a
 temporary file that will not collide with other applications. This
 function raises SysErr if it cannot create the unique file or filename.

Clearly the current SML/NJ implementation [3] ...

 ml_val_t _ml_OS_tmpname (ml_state_t *msp, ml_val_t arg)
 {
     char	buf[L_tmpnam];
     tmpnam (buf);
     return ML_CString (msp, buf);
 } /* end of _ml_OS_tmpname */

... of the tmpName function dates back to the state of the Basis
specification before the acknowledgement of the race condition of
tmpnam.

[1] <http://sml-family.org/Basis/history.html>
[2] <http://sml-family.org/Basis/os-file-sys.html#SIG:OS_FILE_SYS.tmpName:VAL:SPEC>
[3] <http://smlnj-gforge.cs.uchicago.edu/scm/viewvc.php/sml/trunk/runtime/c-libs/posix-os/tmpname.c?view=markup&root=smlnj>
Comment 18 Kurt Jaeger freebsd_committer 2014-08-01 19:43:30 UTC
I'm fine with the patch you suggest. If you want me to commit it, instead of waiting for upstream, please post me a short note 8-}
Comment 19 Timothy Beyer 2014-08-03 00:44:21 UTC
I thought that I'd mention that this port works correctly on 10.0-RELEASE amd64, even though others have already noted this previously.

Using this port, I've built an as of yet unreleased staging and install fix for math/isabelle.  I'm still sorting out pkg-plist issues (Isabelle using SML/NJ takes over 2 hours to compile on a very high spec i7 4770s machine, which unfortunately is completely normal for the compiler), but as far as compilation goes, it definitely works correctly, and I see no regressions in any area relative to prior versions of SML/NJ.

Thanks for your hard work!

Regards,
Tim
Comment 20 Johannes 5 2014-08-16 19:34:08 UTC
(In reply to Kurt Jaeger from comment #18)
> I'm fine with the patch you suggest.

Great. Unfortunately the name of the patch file (i.e. it's name in the
files directory of the port) was wrong: "_objs" has to be removed from
it, otherwise packaging fails when using the port's "EVERYTHING" option.
Sorry for that glitch, but here's a version with the correct path, and
this one also bumps PORTREVISION:

<ftp://offshore.free.de/pub/patch/smlnj.patch.20140815>
MD5 (smlnj.patch.20140815) = 3412ca0fe4cc2cc9864bb2a52c35600a

After patching and installing, one can quickly test if the tmpName
patch is effective using one command line:

% echo 'OS.Process.system ("ls -l " ^ (OS.FileSys.tmpName ())) ;' | sml

The resulting output should look like this:

Standard ML of New Jersey v110.76 [built: Sat Aug 16 20:35:05 2014]
- [autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
-rw-------  1 me  mygroup  0 Aug 16 20:39 /tmp/TMP-SMLNJ.ZYBiay
val it = 0 : OS.Process.status
- 

> If you want me to commit it, instead of waiting for upstream, please
> post me a short note 8-}

I reported the tmpnam issue to upstream [1] (with some losses caused by
their bugform.php;). As there is no response yet, I suggest that you
commit the corrected patch. If upstream will come up with a better
solution to the tmpnam issue in the future, the smlnj port will use it
sooner or later. But getting rid of the cause of the "POSSIBLY
INSECURE" warning as early as it is feasible looks like a Good Idea.

Thanx!
Johannes

[1] <http://smlnj-gforge.cs.uchicago.edu/tracker/index.php?func=detail&aid=128&group_id=33&atid=215>

ps Well, there are a lot more possibilities to improve this port (e.g.
  recompilation on amd64, seperating multiexec-wrapper, hier(7)
  compatibility, documentation, simplification). But reading the feedback
  about the correctness of the port encourages my hope that this commit
  will achieve that this PR can rest in peace:-)
Comment 21 John Marino freebsd_committer 2014-08-31 10:16:04 UTC
remove "stagify" from title.  It's already staged and it's showing up in a search for unstaged ports.

When is this PR going to be closed anyway?
Comment 22 commit-hook freebsd_committer 2014-08-31 10:42:18 UTC
A commit references this bug:

Author: pi
Date: Sun Aug 31 10:42:05 UTC 2014
New revision: 366742
URL: http://svnweb.freebsd.org/changeset/ports/366742

Log:
  lang/smlnj: fix tmpname warning

  PR:		191899
  Submitted by:	joemann@beefree.free.de (maintainer)

Changes:
  head/lang/smlnj/Makefile
  head/lang/smlnj/files/do-patch-base_runtime_c-libs_posix-os_tmpname.c
Comment 23 Kurt Jaeger freebsd_committer 2014-08-31 10:42:48 UTC
Thanks for the tmpname fix. committed. There's 110.77 out, anyway...
Comment 24 Johannes 5 2014-09-02 19:42:22 UTC
(In reply to Kurt Jaeger from comment #23)
> Thanks for the tmpname fix. committed.

Great. From my point of view this PR can be closed now.

> There's 110.77 out, anyway...

Yeah, and it saved me from boredom during the last week;-)
I experienced three issues that crept in during the final stage of the
release process of 110.77:
- upstream's version of the tmpnam fix is not enabled on FreeBSD,
- release tarballs contain MAC OS X resource files, and
- the part of the installer that's written in SML was b0rked, which
  broke the port's RECOMPILE option.

If anyone has the opportunity to test my efforts to cope with those
issues, I'd appreciate to learn about your results. Here's the
patch against the current state (110.76_1) of the smlnj port:

<ftp://offshore.free.de/pub/patch/smlnj.patch.20140902>
MD5 (smlnj.patch.20140902) = 2a4ba3bd8dac5954dae39ea6d8b72313

After applying the patch and installing the port you can run the
tmpnam test, which should give the following (or similar):

% echo 'OS.Process.system ("ls -l " ^ (OS.FileSys.tmpName ())) ;' | sml
Standard ML of New Jersey v110.77 [built: Tue Sep  2 19:47:15 2014]
- [autoloading]
[library $SMLNJ-BASIS/basis.cm is stable]
[autoloading done]
-rw-------  1 me  mygroup  0 Sep  2 21:26 /tmp//SMLNJ-gGyQpp
val it = 0 : OS.Process.status
- 

I'll give this version of the port (110.77) some more testing in the
next days myself and will then submit it in a new PR. (So this PR can
R.I.P.-)

Thanx & cheers!
Johannes