Date: Thu, 17 Jul 2014 16:30:37 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-ports-bugs@FreeBSD.org Subject: [Bug 191899] [MAINTAINER] lang/sml-nj-devel: update to 110.76, unbreak, pkgngify, stagify, +amd64, -gmake Message-ID: <bug-191899-13-7uTupwgCp0@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-191899-13@https.bugs.freebsd.org/bugzilla/> References: <bug-191899-13@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D191899 --- Comment #3 from Timothy Beyer <beyert@cs.ucr.edu> --- (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: >=20 > 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 jai= l, 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-bi= t), and won't compare favorable to your more sophisticated approach, but it sometimes is useful. >=20 > > 1) I modified the PREFIX in multiexec-wrapper to something along the > > lines of /usr/jails/[name_of_jail]/usr/local >=20 > 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 =3D> /usr/lib32/libm.so.5 (0x28081000) > libc.so.7 =3D> /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 =3D> /usr/lib32/libm.so.5 (0x28080000) libc.so.7 =3D> /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 --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-191899-13-7uTupwgCp0>