Recently, I asked the following:
>I just upgraded a 3/280 to a SparcServer 380, and have immediately run into
>a fairly serious problem. C programs compiled on the 4/380 fail when run
>on a SparcStation 1+. Sample output is below:
>
>nsslsun% cd /export/common
>nsslsun% head -1 /etc/motd
>SunOS Release 4.1 (nsslsun) #3: Thu Oct 18 23:50:03 CDT 1990
>nsslsun% cat test.c
>
>main()
>{
> printf("hello, world\n");
> exit(0);
>}
>
>nsslsun% cc test.c
>nsslsun% a.out
>
>hello, world
>
>nsslsun% rlogin tinman
>tinman% head -1 /etc/motd
>SunOS Release 4.0.3c (tinman) #3: Fri Oct 12 15:43:17 CDT 1990
>tinman% cd /export/common
>tinman% a.out
>
>ld.so: warning: /usr/lib/libc.so.1.3.5 has older revision than expected 5
>ld.so: call to undefined procedure start_float from 0x4070
>
>Both workstations have fortran 1.3.1 on them. Fortran programs get the
>warning message, but at least they seem to run.
>
>Anyone have any ideas?
>
> Kevin W. Thomas
>
I received many answers. The concensus is that I either need to upgrade
"tinman" to 4.1, or compile programs on "tinman". I've decided to compile
things on "tinman" now, and upgrade later.
I've included one response below, which seems to summarize what I learned.
>executables are upward compatible only, not downward compatible.
>your 4/380 is running 4.1; your ss-1 is running 4.0.3C. if you
>upgrade the ss-1 to 4.1, then your problem will go away.
>
>start_float() is part of the 4.1 c initialization; it's not in
>4.0.3. since executables are dynamically linked with libc.so,
>the linker just expects to find start_float() at run time in libc.so.
>
>you can *try* to get around this by linking things statically
>(use the -Bstatic flag) but there is still no guarantee it will
>run correctly. linking statically, you will bind in the 4.1 startup
>sequence, but there are still system calls that work differently
>and may produce surprising results.
>
>in general: only move executables to higher-numbered OS releases.
>
>--hal stern
> sun microsystems
> northeast area consulting group
I find it someone disturbing that Hal says that there is no guarantee
with static links. For non-kernel related programs, I would hope static
links would work, but I'm not going to test his answer.
Thanks go to the following people for their replies:
"Dr Gareth J. Barker" <gbarker@mph.sm.ucl.ac.uk>
Kerien Fitzpatrick <fitz@dirt.frc.ri.cmu.edu>
Michael S. Maiten <msm@energetic.com>
apollo@buengc.bu.edu (Doug A. Chan)
casper@fwi.uva.nl (Casper H.S. Dik)
claude@genethon.fr (Claude Scarpelli)
dagobah!mis@uunet.UU.NET (Mark Seiden)
dan@breeze.bellcore.com (Daniel Strick)
dmorse@sun-valley.stanford.edu
fpb@ittc.wec.com (Frank P. Bresz)
halstern@Sun.COM (Hal Stern - Consultant)
jackal@munsell.epps.kodak.com (Phil Hammar)
jhb@maths.su.oz.au (John Brownie)
mark@isis.berkeley.edu (mark kraitchman)
markw@utig.ig.utexas.edu (Mark Wiederspahn)
mitchb@baron.nldn.albany.edu (Mitch Baltuch)
paisley@cme.nist.gov (Scott Paisley)
per@erix.ericsson.se (Per Hedeland)
pjw@usna.navy.mil (Peter J. Welcher)
proton!baumann@ucrmath.ucr.edu (Michael Baumann)
srvarma@sunstroke.acs.syr.edu (Sandeep Varma)
trinkle@cs.purdue.edu
vanandel@stout.atd.ucar.EDU (Joe Van Andel)
vasey@mcc.com (Ron Vasey)
yih%atom@cs.utah.edu (Benny Yih)
Kevin W. Thomas
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:05:59 CDT