Date: Wed, 27 Jan 1999 12:53:22 -0700 From: Nate Williams <nate@mt.sri.com> To: Terry Lambert <tlambert@primenet.com> Cc: nate@mt.sri.com (Nate Williams), java@FreeBSD.ORG Subject: Re: TowerJ for FreeBSD Message-ID: <199901271953.MAA22848@mt.sri.com> In-Reply-To: <199901271940.MAA17619@usr07.primenet.com> References: <199901262347.QAA15778@mt.sri.com> <199901271940.MAA17619@usr07.primenet.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> > > > 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. > > > > No comment? > > I know at least one person who is using the copy from the Sun > download. If you think I'm going to turn them in to be pursued > for license violation, you're crazy. I don't believe they are doing that, and your blowing smoke. > > > > 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... > > > > Shared library, since that's all we have available to us, and what you > > claimed could be done above. Although, I'd settle for a static link. > > (Although I have access to an FreeBSD ELF/Motif library. :) > > The Solaris CD is shared; the download included the full developement > environment. Then shared works for me too. > > > They > > > ended up with only a few unresolved symbols, most ending with "64". O > > > believe the total was less than 10. > > > > See above. Also, the linking is the *easy* part. It's providing the > > 'shim' to convert all of the calls to/from the shlib that's the hard > > part. > > And I think this "shim" is already well documented in the KLD for > the Solaris ABI module. Yes, I don't know for sure if the Solaris > JDK code will run under the ABI, but Oracle does, and so, apparently, > does Lotus Notes. We're talking two different problems here. One is a 'completely' separate SVR4 emulation model, and the other is hybrid of FreeBSD binaries and SVR4 (or other) shared libraries. > I know we all have a bias that the stuff we are doing is harder than > the stuff anyone else is doing, but frankly I can't see that the JDK > would be any more dependent than the other foreign binaries. Never said it was hard, but that it's alot of stuff to deal with since it requires alot of OS hooks, unlike most 'foreign binaries'. (Although I would guess that Oracle would be in the same class because it tries to do lots of 'performance' gaining calls. > > > 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). > > > > I disagree. Select/poo is used all over the place in Motif (the event > > libs), so I doubt even trivial applications would work. > > Implementing select or poll is trivial. Yeah, some FreeBSD device > drivers may have to change; so what? Are we now talking about the > politics of the changes being committed? I don't care about politics, > if that's what we're doing. No, I meant that you have to determine *which* portion of the binary is calling select/poll (the FreeBSD portion or the Solaris portion), and then 'munge' the system to expect that. Basically, what you're trying to do is put a small-block Chevy engine in a BMW. Yes, it can be done, but it's not easy and the resulting car is probably worse than the original Chevy and the BMW in terms of performance and reliability. > > > > 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. > > > > Sure they are. The Solaris ELF library assumes that the constants are > > the same for all the function calls in FreeBSD as they were in Solaris, > > which is the wrong assumption. > > For the most part, this is true. > > For places this is not true, the answer is easy: change FreeBSD. Then you lose backwards compatability with FreeBSD, which arguably has a larger installed based than Solaris/x86. In other words, that's a stupid idea. > Put it another way: there's no way we're going to be able to change > Solaris, so FreeBSD is the only thing that *can* be changed. Put it another way, cutting off your nose to spite your face is still stupid. > > Also, you have to assume that none of > > the shlib include files (the ELF Motif and/or JIT) also make any > > assumptions about the OS in question that are invalid (filename size, > > etc...) > > > Yeah. I'm making the assumption that this is either true, or very > nearly true, and for the places it isn't that truss and a copy of > Solaris in hand (with it's truss to compare against) would be enough. All of a sudden this 'trivial' excercise is no longer trivial. (My definition, not yours.) You claimed a weeks work, and we're *way* beyond that now. > > > System calls would be an issue if I were trying to use Solaris's > > > libc; I'm not. > > > > You have to look like Solaris's libc, because the shlib is expecting > > that 'ioctl(a, b, c)' looks the same in FreeBSD as it does in Solaris, > > as the JIT is calling them. > > The ioctl() is much less of a problem, IMO. I don't think it's that > frequent, and where it *is* used, I have no problem hacking up either > a non-weak wrapper in a stub or, preferrably, FreeBSD. IOCTL is used *ALL OVER* to setup socket timeout and such. It's non-trivial. > > > 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. > > > > Right. As with all of your ideas, one/two weeks worth of work and > > things'll be there, so why bother. > > No, the "why bother" comes from this not being intellectually > challenging, and me wanting to spend my free time being challenged; > otherwise I'd be watching TV. Terry, you have *yet* to complete a project in FreeBSD/NetBSD/etc.. , because as soon as they get 'interesting' (otherwise known as finishing the details that make the proof of concept usable beyond trivial applications), you throw your hands up in the air and claim the remaining stuff is 'trivial' to implement, when in fact as has shown that finishing those projects that have been adopted is *FAR* from trivial. In other words, you're being lazy, and 'trivial' is a good excuse to avoid doing the hard work. > > > > 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". > > > > Then use a different word instead. Trivial implies 'easy, nothing much > > to do'. > > Not to a mathematician or a scientist, it doesn't. Sure it does. You're no more a mathematician or a scientist more than I, and I consider the word incorrect. > > Working for one of the world's largest research institute makes it > > obvious (at least to me) that really good ideas come along infrequently. > > There are tons of good ideas. I personally have more ideas that I > believe are good than I'm going to be able to execute within twice > my expected lifetime. I'm forced to pick and choose. And never finish *any* of them. :( Nate 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?199901271953.MAA22848>