Date: Tue, 26 Jan 1999 23:27:01 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: nate@mt.sri.com (Nate Williams) Cc: tlambert@primenet.com, Nate@primenet.com, Williams@primenet.com, nate@mt.sri.com, Mats@primenet.com, Lofkvist@primenet.com, mal@algonet.se, java@FreeBSD.ORG Subject: Re: TowerJ for FreeBSD Message-ID: <199901262327.QAA05210@usr01.primenet.com> In-Reply-To: <199901262226.PAA14679@mt.sri.com> from "Nate Williams" at Jan 26, 99 03:26:38 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > > Really hard. Hard enough that it will probably never be done. See > > > postings on hackers on this where Terry Lambert bogusly declared it was > > > trivial without understanding the details. > > > > The library is ELF, and is unrelocated, so it isn't Solaris specific > > excepet for partially preresolved jump table vector names. > > Wrong. It makes Solaris system calls, using Solaris parameters and > Solaris defines. The libc does. The other libraries make their calls by way of libc symbols. You replace the libc, you replace the calls (but not the parameters). The parameters are only problematic if people are doing complicated things, like directly controlling devices, ejecting CDROM's, etc.. > > In general, the dependency is that most of these libraries are linked > > against the Solais libc, and bring in symbols from there. > > Right. A FreeBSD 'binary' can't make Solaris libc calls correctly. No, but it can bring the same symbols in from a FreeBSD libc, and thereby make FreeBSD libc calls. See the Linux SCO ABI code for details. > > For example, a number of people have been using the Solaris CDE ELF > > library to get an ELF Motif 2.0 implementation that they can link > > against, since Sun used to offer the thing for download from their > > WWW site, and you can get it on the Solaris "free" ($15) CDROM. > > Nobody has been using the Solaris CDE ELF library to build FreeBSD > binaries. As was pointed a while back, you can't 'mix' a Solaris > library and a FreeBSD binary. I'd even buy you dinner if you can > make anything beyond a simple toy application work with the Solaris > library. > > I've got a FreeBSD native application that uses Motif. I'll bet you > dinner that you can't make it work with the Solaris ELF library. Static library? This is almost worth giving up my Motif-taint-free status to make work... > > It's pretty trivial (contrary to Nate's claims) to find the list of > > interfaces affected by just truing to link the Motif library > > directly. You'll get a list of unresolved externals. > > Prove it. Really, I'd love for you to prove me wrong. > > Hand-waving a long email messages stating that it's trivial mean nothing > when in fact it doesn't work. Actually, if you look over the -current list archives, you'll see that someone tried and failed to link the Solaris Motif libraries. They ended up with only a few unresolved symbols, most ending with "64". O believe the total was less than 10. That should mean that you could get it linking with about 30 minutes of light work, and that you could probably have trivial programs (e.g., the ones in the "Young" and "O'REilly" Motif books) running in a relatively short period of time (say a day at most, with SEF's truss and Mark's Solaris ABI KLD in hand). > Issues such as system calls (which are the biggest problem), System calls aren't really relevent, since the calls are by way of whatever libc you link against. The biggest problem is the manifest signal constants (at least for Motif). JDK is a bigger issue, since it exposes more system interfaces. System calls would be an issue if I were trying to use Solaris's libc; I'm not. JDK libraries would probably take up to five days to make work, if you had the working Motif libraries on which JAVA depends on Solaris in hand. Probably, it's just be easier to make Sun's JAVA work under Solaris emulation. If you're going to grab their libraries, you might as well grab the shared onese, at least initially. > different library functions, etc.. can all be worked around, but > not 'trivialy'. I think you are misunderstanding my use of the word "trivial". It's a measure of complexity of the problem. If you want, you can translate it each time you see it to "there's not a lot of thought required". Digging a 500 foot long trench 1 foot deep in relatively good soil with few rocks using nothing but hand tools, for example, is trivial, but it's not something you are going to do by taking an hour one afternoon. In other words, something that is trivial is "grunt work", lacking in intellectual challenge. > If SVR4/Solaris emulation was a worthwhile goal, someone could > continually maintain it like we do with the Linux emulation, but the > fact of the matter is that it's not worth it (both in terms of the code > required as well as the complexity in trying to switch to 'Solaris' > mode from 'FreeBSD' mode and back in a single binary.) And that conclusion is based upon what? The relaive number of applications available from commercial vendors for each OS? Trivial frequently means "not interesting to solve" or "not a challenge"; it's had to get volunteers to do boring work, especially when you discourage them from trying in the first place. >From what I can see, FreeBSD could use all the grunts it can get, if only to play catch-up to Linux. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-java" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901262327.QAA05210>