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)
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.
(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.)
(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
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.
(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
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!
(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
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?
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 ?
(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
(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
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.
(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.
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
Committed, thanks all for the hard work. Now, please go and test and tell me where I failed 8-)
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)
(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>
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-}
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
(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:-)
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?
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
Thanks for the tmpname fix. committed. There's 110.77 out, anyway...
(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