Date: Fri, 20 Feb 1998 19:25:19 -0500 From: Randall Hopper <rhh@ct.picker.com> To: "Daniel O'Connor" <doconnor@gsoft.com.au>, Amancio Hasty <hasty@rah.star-gate.com> Cc: multimedia@FreeBSD.ORG Subject: libglide2x.so -- How about an auto-port? (was Re: Mesa + Voodoo 3dfx) Message-ID: <19980220192519.16455@ct.picker.com> In-Reply-To: <199802180025.KAA07403@cain.gsoft.com.au>; from Daniel O'Connor on Wed, Feb 18, 1998 at 10:55:34AM %2B1030 References: <19980217223140.36184@tao.org.uk> <199802180025.KAA07403@cain.gsoft.com.au>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --]
Daniel O'Connor:
|You must get the linux developement kit, and then compile Mesa for linux.
I was just thinking. If we don't manage to stir up help from the 3dfx
folks for doing a FreeBSD-native glide port (way too early to call that
one), I was wondering abut the practicality of doing an automated-port
ourselves.
(Huh? What?) Well, it seems there are two pieces to a port:
1) turning the Linux-specific library dependencies (libc, etc.) into
FreeBSD dependent interfaces
2) ELF -> a.out conversion.
As to the first,
we already have this in an emulation layer in the kernel. If you look
at the symbol dependencies in libglide (see attachment), the list is
small and most are pretty standard libc symbols with likely just minor
diffs between the FreeBSD and Linux implementations. A few are
foreign, but we can emulate them (apparently). No sweat.
Seems we might be able to cook a minimal "liblinux.so" for a "tweaked
libglide2x.so" to depend on which would translate the linux shlib
calls to freebsd shlib calls. However, I don't know if this is very
reasonable, not being intimately familar with the link tools and
libraries out there (libbfd, etc.) which would hopefully allow for
manipulating a dynamic object. Crazy? I don't know; just a thought.
As to the second,
No idea. Is it 1. easy, 2. hard, 3. ridiculous to even think of an
automated conversion of a library from Linux ELF format to FreeBSD
a.out format?
Now I'm not suggesting this as a solution for general porting of Linux libs
or apps. But if we could come up with an automated production that'd cook
a FreeBSD a.out libglide2x.so from a Linux libglide2x.so which we could just
hand over to 3dfx -- no effort required on their part, I'm sure iD, et
all might be more likely to provide native 3dfx support for us. 3dfx,
seeing how little effort would be involved for a source port, would be that
much more likely to just #ifdef the Linux glide source and build a native
FreeBSD version from source.
And of course we wouldn't have to waste all that extra memory and hastle
with resident Linux shlibs, cross-compiling everything, ...
Maybe I'm just dreaming... Any thoughts from those more informed about
emulation and libraries?
Randall
[-- Attachment #2 --]
00000000 D *UND* 00000000 fopen
00000000 D *UND* 00000000 __uflow
00000000 D *UND* 00000000 sscanf
00000000 D *UND* 00000000 __ctype_b
00000000 D *UND* 00000000 __ctype_toupper
00000000 D *UND* 00000000 strcmp
00000000 D *UND* 00000000 fclose
00000000 D *UND* 00000000 memset
00000000 D *UND* 00000000 fread
00000000 D *UND* 00000000 pow
00000000 D *UND* 00000000 exp
00000000 D *UND* 00000000 malloc
00000000 D *UND* 00000000 getenv
00000000 D *UND* 00000000 __strtol_internal
00000000 D *UND* 00000000 sprintf
00000000 D *UND* 00000000 strcpy
00000000 D *UND* 00000000 puts
00000000 D *UND* 00000000 exit
00000000 D *UND* 00000000 uname
00000000 D *UND* 00000000 _IO_stderr_
00000000 D *UND* 00000000 fprintf
00000000 D *UND* 00000000 fgetc
00000000 D *UND* 00000000 fgets
00000000 D *UND* 00000000 strtok
00000000 D *UND* 00000000 fwrite
00000000 D *UND* 00000000 feof
00000000 D *UND* 00000000 fflush
00000000 D *UND* 00000000 __overflow
00000000 D *UND* 00000000 strchr
00000000 D *UND* 00000000 times
00000000 D *UND* 00000000 strncpy
00000000 D *UND* 00000000 strcat
00000000 D *UND* 00000000 tcsetattr
00000000 D *UND* 00000000 tcgetattr
00000000 D *UND* 00000000 cfmakeraw
00000000 D *UND* 00000000 atexit
00000000 D *UND* 00000000 select
00000000 D *UND* 00000000 read
00000000 D *UND* 00000000 iopl
00000000 D *UND* 00000000 open
00000000 D *UND* 00000000 mmap
00000000 D *UND* 00000000 close
00000000 D *UND* 00000000 munmap
00000000 D *UND* 00000000 _IO_stdout_
00000000 D *UND* 00000000 vfprintf
00000000 D *UND* 00000000 printf
00000000 D *UND* 00000000 __ctype_tolower
00000000 D *UND* 00000000 __strtod_internal
00000000 D *UND* 00000000 clock
00000000 D *UND* 00000000 putenv
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19980220192519.16455>