[Bug 191899] [MAINTAINER] lang/sml-nj-devel: update to 110.76, unbreak, pkgngify, stagify, +amd64, -gmake

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=191899

--- Comment #3 from Timothy Beyer <beyert at 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:
> 
> 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 at zzz:~ # uname -srm
> FreeBSD 9.2-STABLE amd64
> root at zzz:~ # sysctl security.jail.jailed
> security.jail.jailed: 1
> root at zzz:~ # pkg info -x sml
> smlnj-devel-110.76
> root at 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

-- 
You are receiving this mail because:
You are the assignee for the bug.