Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 7 Jun 1995 18:28:20 -0400 (EDT)
From:      "House of Debuggin'" <wpaul@skynet.ctr.columbia.edu>
To:        hackers@freebsd.org
Subject:   BSDi 2.0 binary compatibility question
Message-ID:  <199506072228.SAA00374@skynet.ctr.columbia.edu>

next in thread | raw e-mail | index | archive | help
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 <stdio.h>

  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 <stdio.h> 
  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!" ~~~~~~~~~~



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506072228.SAA00374>