Date: Sun, 4 Oct 1998 13:27:43 -0400 (EDT) From: Brian Feldman <green@zone.syracuse.net> To: Chuck Robey <chuckr@mat.net> Cc: Martin Cracauer <cracauer@cons.org>, Terry Lambert <tlambert@primenet.com>, nate@mt.sri.com, osa@etrust.ru, current@FreeBSD.ORG Subject: Re: What about jdk-1.1.6 for FreeBSD-3.0-ELF ? Message-ID: <Pine.BSF.4.04.9810041320510.16118-100000@zone.syracuse.net> In-Reply-To: <Pine.BSF.4.02A.9810041231320.362-100000@picnic.mat.net>
next in thread | previous in thread | raw e-mail | index | archive | help
I do understand more than you think I do. I know about kernel- and user-land, how system calls work, etc. What I meant is: in a dynamic library, there should be NO raw __syscall/syscall'ing, the choices of howt o do system calls should be in the system libc. The only real incompatibilities in the actual libraries would be compiler-specific, or libc-specific (those *64 calls etc, for solaris only), like with libgcc.a-compiled libs on non-GNU-cc-systems. The ACTUAL function calls, as defined by ELF, that call functions, defined by ANSI, should not in any differ except across architectures. -Brian Feldman On Sun, 4 Oct 1998, Chuck Robey wrote: > On Sun, 4 Oct 1998, Brian Feldman wrote: > > > Cheers, > > Brian Feldman > > > > On Sun, 4 Oct 1998, Martin Cracauer wrote: > > > > > In <199810040411.VAA25038@usr06.primenet.com>, Terry Lambert wrote: > > > > > I'm taking from this that not having a Motif lib in elf is dragging > > > > > things back. I'm totally non-suprised (I've been nagging XiG to get by > > > > > personal favorite one done for a while now). I would hope that, when > > > > > someone _does_ find a vendor of Motif in ELF, there will be a quick > > > > > announcement on the lists ... don't consider it advertising, we _need_ > > > > > this. > > > > > > > > Someone needs to flush $15 on the "free" Solaris and/or UnixWare CDROM, > > > > which has an ELF Motif library on it. > > > > > > And this library won't use any system or libc calls that might be > > > incompatible in FreeBSD? > > > > I don't see why a system call should be incompatible since being a shared > > library, the system call is just a definition of a link to the true libc > > symbol. > > That's because of two things, the semantics of the libc call, and the > way that OS calls are done. In the semantics, I'm referring both to > what precisely the call does, which varies sufficiently to be a major > headache, and the number/order of arguments. It's not standard, Brian. > > The other thing, about the way that OS type calls (like, say, unlink) > which the libc does not in itself handle are done. The libc can't > unlink a file, it has to pass the request to the kernel, and it does > that by using an integer numbered thing called a syscall, where the > kernel recognizes what's being asked of it by the number of the call, > and never sees "unlink". If the libc wrapper for your call thinks the > number for the call is one thing, but the kernel thinks it's another, > boom. > > It's not just "a definition of a link to the true libc" at all. > > ----------------------------+----------------------------------------------- > Chuck Robey | Interests include any kind of voice or data > chuckr@glue.umd.edu | communications topic, C programming, and Unix. > 213 Lakeside Drive Apt T-1 | > Greenbelt, MD 20770 | I run Journey2 and picnic (FreeBSD-current) > (301) 220-2114 | and jaunt (NetBSD). > ----------------------------+----------------------------------------------- > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.04.9810041320510.16118-100000>