From owner-freebsd-hackers Wed Jun 7 16:32:00 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id QAA22532 for hackers-outgoing; Wed, 7 Jun 1995 16:32:00 -0700 Received: from skynet.ctr.columbia.edu (skynet.ctr.columbia.edu [128.59.64.70]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id QAA22525 for ; Wed, 7 Jun 1995 16:31:56 -0700 Received: (from wpaul@localhost) by skynet.ctr.columbia.edu (8.6.8/8.6.6) id SAA00374 for hackers@freebsd.org; Wed, 7 Jun 1995 18:28:23 -0400 From: "House of Debuggin'" Message-Id: <199506072228.SAA00374@skynet.ctr.columbia.edu> Subject: BSDi 2.0 binary compatibility question To: hackers@freebsd.org Date: Wed, 7 Jun 1995 18:28:20 -0400 (EDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 4704 Sender: hackers-owner@freebsd.org Precedence: bulk So, is it supposed to work, or isn't it? One of the people here recently purchased a new Dell Pentium system for personal research purposes and they decided to purchase a BSDI 2.0 binary license for it (mainly to write simulation programs with large memory requirements that DOS can't satisfy). In exchange for helping to install it, I was given account on the machine for playing-around purposes. Today, I decided to see just how binary compatible BSDI is with FreeBSD. I used a FreeBSD-current system (current as of May 17th at least: I haven't had much time lately to stay up to date) and a FreeBSD 2.0.5A system to test with. Both are 386 machines. I even tried freefall and thud just for kicks. Here's what I discovered: - First of all, BSDI 2.0 ships with 2 compilers: gcc 1.42 (cc) and gcc 2.6.3 (gcc). I tried them both. Also, making a binary that uses shared libraries requires compiling with special commands (shlicc, shlicc++ and shlicc2) that are actually shell script wrappers which figure out what libraries to use and do some sleight of hand to get the linker to do do the right thing. - A statically linked FreeBSD binary will run just fine on the BSDI 2.0 system. I used a statically-linked tcsh executable for the test: the shell starts up fine and works great. /bin/csh and /bin/ls work too. The BSDI file(1) and nm(1) commands doen't recognize the executables, but they run anyway. - A statically linked program from BSDI 2.0 doesn't run at all on FreeBSD. Even a dummy program like this: main() {} produces only one result: a SEGV. I tried producing simple 'Hello World' programs with the BSDI compiler and each time got only seg faults and core dumps. For example: [/home/wpaul]:cordelia.ctr.columbia.edu{94}% uname -sr BSD/OS 2.0 [/home/wpaul]:cordelia.ctr.columbia.edu{95}% cat test.c #include main() { printf ("Hello world...\n"); } [/home/wpaul]:cordelia.ctr.columbia.edu{96}% gcc -g test.c [/home/wpaul]:cordelia.ctr.columbia.edu{97}% file a.out a.out: 386 compact demand paged pure executable not stripped (Note that gcc produces a static binary by default. Using shlicc2 would have prodiced a binary linked against the shared libs.) [ftp a.out and test.c to the FreeBSD machine] [/tmp]:bootserv{41}% uname -sr FreeBSD 2.0.5-ALPHA [/tmp]:bootserv{42}% file a.out a.out: BSD/386 demand paged (first page unmapped) pure ex [/tmp]:bootserv{43}% ./a.out Segmentation fault (core dumped) [/tmp]:bootserv{44}% gdb a.out GDB is free software and you are welcome to distribute copies of it under certain conditions; type "show copying" to see the conditions. There is absolutely no warranty for GDB; type "show warranty" for details. GDB 4.13 (i386-unknown-freebsd), Copyright 1994 Free Software Foundation, Inc... (gdb) list 1 #include 2 3 main() { printf ("Hello world...\n"); } (gdb) run Starting program: /tmp/a.out Program received signal SIGSEGV, Segmentation fault. 0x1055 in start () (I'd like to know why file(1) only prints 'ex' instead of 'executable.') Unfortunately, I wasn't able to try a statically linked system binary from the BSDI machine on my FreeBSD machines, largely because there don't seem to be any: the entire system seems to consist of dynamic executables, including /sbin/init. The exceptions are as follows: - Xaccel, the commercial X server, is a static binary. However, the timestamp on it says it dates back to November 1994, which leads me to believe that it wasn't compiled on BSDI 2.0. - Netscape. This is version 1.0, the one with the throbbing 'N' symbol. - Mosaic. It looks like version 2.4. I think that it, like Netscape and Xaccel. was compiled on a BSDI 1.1 system and the binaries were simply copied over. In short, I couldn't find a magic incantation to make BSDI 2.0 produce executables that would run on FreeBSD, even though FreeBSD seems to recognize the executable format. I think it's kind of unfair that BSDI people can use our binaries, but not the other way around. Am I missing something here, or is this a bug? -Bill -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~T~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Bill Paul (212) 854-6020 | System Manager Work: wpaul@ctr.columbia.edu | Center for Telecommunications Research Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ The Møøse Illuminati: ignore it and be confused, or join it and be confusing! ~~~~~~~~~ FreeBSD 2.1: "We can kick your operating system's ass!" ~~~~~~~~~~