ELF dynamic loader name [was: sbrk(2) broken]
andrew-freebsd at areilly.bpc-users.org
Mon Jan 7 22:05:21 PST 2008
On Mon, 07 Jan 2008 22:30:18 -0500
"Alexandre \"Sunny\" Kovalenko" <alex.kovalenko at verizon.net>
> > [I'm doing a lot of my own new coding in PLT scheme at the
> > moment, and having a ball with it. (lang/drscheme in ports)
> I suspect you are not running contemporary 7.0 there:
> twinhead# uname -a
> FreeBSD twinhead.rabbitslawn.verizon.net 7.0-RC1 FreeBSD 7.0-RC1 #0: Tue
> Jan 1 19:22:56 EST 2008
> root at twinhead.rabbitslawn.verizon.net:/usr/obj/usr/src/sys/TWINHEAD
> twinhead# make install
> ===> drscheme-370 is marked as broken: Fails to install (signal 11).
> *** Error code 1
> Stop in /usr/ports/lang/drscheme.
andrew at duncan:/usr/home/andrew $ mzscheme
Welcome to MzScheme v372 [3m], Copyright (c) 2004-2007 PLT Scheme
andrew at duncan:/usr/home/andrew $ uname -a
FreeBSD duncan.reilly.home 7.0-PRERELEASE FreeBSD 7.0-PRERELEASE
#6: Sat Jan 5 17:53:17 EST 2008
root at duncan:/usr/obj/usr/src/sys/DUNCAN amd64
You'll find a patch with my name on it at:
That fix has been incorporated up-stream, so 372 now builds
cleanly for me from tarballs, but something is still broken on
jkoshy's 8-current system, so he hasn't updated the port yet.
> > Fast enough for what I'm doing, byte-code, static or JIT compiled,
> > and runs everywhere (including Windows and OSX).]
> > What would be *really* cool would be the ability to have a JVM or
> > LLVM back-end in the kernel, as a first-class peer of the ELF
> > loader. Anyone know if anyone has tried such a thing on *BSD (or
> > even Linux, I guess)?
> If you have Linux distribution handy, you can look
> at /usr/src/linux/Documentation/binfmt_misc.txt.
Thanks for the pointer: that's pretty close to what I was
thinking of. There's also the PE loader work in NetBSD...
> At least its Java
> incarnation has been around for a while. I have not seen widespread use
> of it, but then again, I have not been looking too hard.
Yeah, most existing foreign-executable formats have lots of
extraneous environment cruft related to compatibility with
other operating systems, that doesn't really lend themselves to
this sort of application. On the other hand, an LLVM or QEMU
launcher could be trying to run "native" freebsd applications,
just ones that hadn't been fully compiled yet. Sort of like
FX-32! on Alpha Windows-NT, or the e-coff (?failing memory?)
high-level object format produced by the MIPSCO compilers to
enable full-program optimization with separately-compiled
libraries. One of these day's I'll have a go at it, if someone
else doesn't get to it first...
[This is more -arch or -talk than -current, so I'll stop now.]
More information about the freebsd-current